Why can an "Anonymous" user make changes?

I just received a question from a user. He was able to make a change as "Anonymous", i.e. without being logged in.

We use LDAP authentication, and the users should be required to login. Do you have a quick idea where I may have made incorrect settings? Normally, anonymous users should be able to look but not touch.

His description of the actions taken, and a screenshot of the result:

I managed to reopen an issue as an anonymous:

Anonymous made changes - Today 11:00 Integrated [ 5 ] -> Open [ 3 ].
This is really bad :)

Session timed out, and I didn't notice, I wanted to reopen anyway, so no harm was done .

3 answers

1 accepted

2 votes
Accepted answer

Check two things:

1. Who can "browse" the project?

2. The workflow. What "conditions" do you have on the transition "Integrated -> Open"? If it's none, then anyone who can see the issue can do that transition. Well worth adding something like "user must be in the role of user" or something to block anonymous access to the transition.

Good point. I was facing the issue that read-only users (no edit permission) could still transition an issue which in my point of view should somehow be "included" in the edit issue permission... Nevertheless, without being logged in, shouldn't JIRA ask for credentials no matter what the user is trying to do?

No, it shouldn't ask for credentials. If it did, you couldn't have an anonymous-browse system, which is a very useful thing for a lot of people.

I don't think there's another way to do security and permissions in Jira, but I really don't like the defaults that Atlassian provide. If they wanted to do it properly, then they would

1) default a condition on to ALL newly created transitions of something like "person must be a user in the project". It's not going to suit many of us, but it will catch these situations and it's sure as heck going to make the admin writing a new workflow *think* about conditions

2) stop using jira-users in permission schemes by default. Split it in two - a group for "can log in" and a group for "default group who can do stuff in Jira"

Thanks Nic - it turned out that a few of our custom transitions did not have any conditions.

I also agree with you that actions that affect an issue (ie not read-only) should be reserved by default to logged-in users.

For those interested, here is the recipe I used to fix our problem:

Administration > Issues > Permission Schemes
my_permission_scheme [Permissions]
"Project Permissions"
Browse Project - [Add] Group (Anyone) - was already present in our case
"Issue Permissions"
Create Issues - [delete] Group (Anyone) - was not present in our case
Edit Issues - [delete] Group (Anyone) - was not present in our case

Administration > Issues > Workflows
my_workflow [Edit] - starts editting a draft of my_workflow
[All] tab
[Add] Condition
o Permission Condition
my_permission [Add]
[Publish] the draft of my_workflow, making a backup if desired

Your choices of type and restriction for a "Condition" may of course differ from mine.

You should see my recipe for lasagne ;-)

ciao - jOhn.

Strange. On your general configurations page, what mode is JIRA running in, Private or Public? It should be Private...

yes, it is private.

- jOhn

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,495 views 15 20
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you