I have a task to create a Jira (Server) project report and then create an address which will allow for anonymous access to this report.
So far I have done some research an I got few ideas which are based on using the os_username=testUsername and os_password=the_password attributes attached to the URL.
The problem with this solution is the security. My Jira is working over https and sharing a plain text access to a user is a no go.
I already have spoken with our Unix admins and they proposed to create an address (jira.com/reportA) link which will direct traffic to Apache server which will then translate it into a proper Jira report address (jira.com/secure/report?os_username=user&os_password=password)
But this poses another security threat - if someone opens the link, such person will be logged in and have all the freedom to navigate in Jira. This is another no go.
So I'm now thinking about couple possible solutions:
What do you guys think?
I will appreciate you thoughts!
Hi Dastin,
I'd recommend checking out the KB Anonymous User does not have Access to JIRA Agile Features after Upgrade to JIRA 7. This was a common complaint in regards to Jira 7 changes that were made to the platform. Previous versions of Jira allowed more dashboard/reporting accessibility for anonymous users.
In Jira 7, it's really not possible in most cases. As such having a single service account is the recommended solution. However I challenge the idea that having this account would necessarily grant these users access to everything in Jira.
You would want to make sure that the permissions of that account are not allowing those users to create/view/edit issues and projects in Jira that they should not have access to, but that is something that you can easily do by adjusting the project permissions. It could be a delicate balance you might have to work through in order to make sure that this service account still has the access to view the issues/reports needed, but then does not have the permissions to perform other unwanted actions by that account.
I think this is the better approach to this problem instead of trying to hack away at session timeouts and other configurations.
Let me know what you think, or if you have any concerns with this idea.
Andy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.