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 .
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
Browse Project - [Add] Group (Anyone) - was already present in our case
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
o Permission Condition
[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.
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot