nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Why can an "Anonymous" user make changes?

jOhn Simonson

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:

http://atsrnd05.spin.local:8080/browse/SEMEKOGS1-709
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 .

Accepted answers

Nic Brough -Adaptavist-

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.

All comments

Christian Czaia [Decadis AG]

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

jOhn Simonson

yes, it is private.

- jOhn

Nic Brough -Adaptavist-

Check two things:

1. Who can "browse" the project?

Christian Czaia [Decadis AG]

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?

Nic Brough -Adaptavist-

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"

jOhn Simonson

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
my_beginning_state
my_outgoing_transition
[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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration