I want to display JIRA details such as issue titles, a version roadmap, and the issues raised/resolved graph for projects in a Confluence site. This is fine for folks that are logged in but I need it to work for anonymous access as well. I don't want to have to set up anonymous access in JIRA for the project as it contains other details in the comments, etc.
I have followed everything that I can find as far as setting up Application Links between the two and can get the issues to display if I enter an account in the Basic Access tab of the application links.
Using the developer tools in the browser I can see an OAuth error when the gadget on the Confluence page tries to make a request.
Is there a way that Confluence can impersonate another user when it queries JIRA?
Seems to me that you want to do something impossible. As I understand it, there are the following options for using JIRA content inside Confluence:
Use the authenticated user of Confluence in JIRA.
Use an anonymous user for public issues in JIRA.
Use a pre-determined user (not recommended): This will show in public the user name and password in Confluence.
So you have the following options:
Use issue security in JIRA, and set the comments in your issues only be available for a special group.
Ensure that the users you want to get access to are not contained in the special group.
See the documentation about "Trusted Communication", especially the following part:
Display the JIRA issues which the logged-in user is authorised to see. And if the user is not logged in, display only issues which allow unrestricted viewing.
Related
We have ASP.NET MVC applications. We have our own IdP for SSO, The IdP issues authentication ticket using OpenID Connect Protocol. Users can access all our applications by singing once.
We want to use JIRA ticketing system for users to create ticket.
We can create account for every user and provide link on UI to JIRA to create ticket. However that is not convenient if we have large number of users, and keep growing.
We can also create a form in our applications and then submit the form to JIRA using their API. However I am trying to avoid this option because then I have create form in every application and maintain it.
Ideal optional would be, when user clicks on the create ticket link, it should get redirected to JIRA ticketing system, MUST get authenticated implicitly (maybe using access token) and be able to create ticket using JIRA's ticketing system.
Is this possible? Can someone please provide guidelines
You should consider using JIRA's built-in IssueCollector.
This is super simple to set up, and you can find more info here
Unless you need to do something really custom, then this should work out of the box.
I have developed a TFS web extension. I have some auxiliary data that I've placed on a separate page, which is currently accessed from a hub. I want to restrict access to that data so that it can only be changed by people with certain permissions (e.g. only people who have the "Manage project properties" set to Allow).
Both hubs were created by following these instructions, but it doesn't seem to mention how to restrict access to the hub.
According to this, I can't restrict access to a hub group, and it sounds like this may also apply to a hub.
Is it possible to hide the hub based on the user's permissions? If not, what are my options for restricting access to the auxiliary data?
Yes, this is also apply to a hub. At the code level, as a extension author, you could not limit your extensions' access to specific users or groups.
For now, there is also no way to specify the users or groups to access the installed extension in web portal or server side (expect the priced).
There has been a related user voice, you could vote and follow up, TFS PM will kindly review the suggestion.
VSTS extension restrict for specified users or groups
https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/32926549-vsts-extension-restrict-for-specified-users-or-gro
One way maybe work: if a user doesn't have access to the various data that the extension pulls from TFS/VSTS, they will have parts of this extension not work. However, you could not hide the extension and its link entirely for a user by now.
In servlet programming, I have a html login page in which I ask for username and pass for a user and when he enters the details all issues assigned to him are displayed. Furhter when he clicks on any of it he gets navigated to issue page.
Here I am facing a problem that whenever clicks on issue link it opens in new tab and ask for his credentials again. What I want to do is to maintain the same session(JSESSIONID) which he logged in on my html login page.
I am using JIRA rest api for login and fetching details.
How do i achieve it..?
The REST API is used to connect between your server-side app and JIRA, not between the user's browser and JIRA (with the latter being where you need to establish the authentication for viewing the issue detail page).
Assuming you have a behind-the-firewall instance of JIRA Server, your options are:
Convert your servlet to run as a JIRA Plugins 2 add-on and run it within JIRA itself (meaning that users would leverage the JIRA authentication framework to log in before accessing your servlet in the first place), or
Write a custom Single Sign-On authenticator for JIRA that will accept whatever credentials you have set up for the user in your external servlet. This is a nontrivial solution, so depending on the complexity, it may be easier to just do #1.
I have two projects in JIRA: software project and service desk project.
My goal it to enable my service desk customers to access the software project but in a limited way. E.g.:
clients could create stories,
comment on them,
assign priorities
and assist with assigning them to iterations / releases.
But they would not be able to perform and see some actions e.g.:
see the logged time
and ideally to keep some of the ticket / story fields and comments as internal use only so I can have technical discussions with my team without the client seeing them etc.
I can see in documentation that "Service Desk Customers can't log in to JIRA applications":
https://confluence.atlassian.com/servicedeskcloud/setting-up-service-desk-users-732528877.html
But is there any workaround to give Service Desk Customers access to JIRA applications? Is there any simpler method than making a REST API bind? If yes, then how it could be achieved?
The documentation is not clear. Add their accounts to the jira-users group and they will be able to log into JIRA as regular users. The point is that member of jira-users consumes a JIRA user license, while "pure" customer account does not.
As regular regular users they will have permissions just as you configure your project Permission Scheme, so everything is in your hands. Using roles you can restrict issue comments to those roles. There's also nice Comment Security Default plugin to use with that.
Right now I'm trying to get Atlassian's basic JQL standalone gadget template working with my Confluence install (found here: https://developer.atlassian.com/display/JIRADEV/Writing+a+JQL+Standalone+Gadget). It renders just fine when I bring up the preview window, but it seems that the gadget kicks me out of my Confluence session as soon as it renders. This makes it impossible to place onto the page, and of course, impossible to use. Right now I have both OAuth and Atlassian Application links set up between my instances, what could possibly be causing this behavior?
Do you have your JIRA and Confluence instances on the same hostname but on different ports? To get the Application Links to function properly, you will want your JIRA and Confluence on two separate hostnames. Trying to use http://localhost:8080 for JIRA and http://localhost:8090 for Confluence is asking for trouble, especially for things like cookies and OAuth.
You don't need to move the servers at all, but you do need to set up different hostnames. For example, edit /etc/hosts to add "127.0.0.1 conftest jiratest" and then access them as http://jiratest:8080 and http://conftest:8090.
Once you've made those changes, make sure that you go into each application and reconfigure the base URL in the admin console according to whatever it is that you decided above, then delete and recreate the application links, delete and recreate the external gadget feed, and try again.
You may also want to turn on the Trusted Application feature in both the incoming and outgoing authorization for the application link (scroll down when you are configuring it—some parts of that dialog may not be visible above the fold). (Though maybe this is what you meant by "Atlassian Application links"?)