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"?)
Related
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 built an application in Visual Studio, ASP.NET MVC for the company I work at. It is only accessible on our intranet, and uses Windows Authentication to validate the user. There are a few pages that I only want a few users to be able to view, and have restricted access to only those few. The problem is that multiple people use one computer. I need the people that are able to view the few pages to log out when they are done so that others cannot access the page. Right now, I have them closing out the browser, and that logs them out.
The log off button is visible at the top of the screen, but does nothing. Is it possible to use the log off button as well as Windows Authentication?
I have impersonation set to "on" within IIS.
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.
We are building a new web application that needs to run inside the SP Context for authentication. Unfortunately the person logged into the machine is not necessarily the person logged into SharePoint. I could not figure out a way to detect who was logged into SharePoint from an application outside of SharePoint. So, the solution is to deploy the application to the LAYOUTS folder within the 12 hive. This works great in that I can use a custom master page, go crazy with fancy user controls, AND be within the SP Context. I also locked down access to the page by detecting which web app the user was on so no one can access it from a different SP web app.
The problem is the URL. It is ugly. I want the url to be something like this: www.sitename.com/ instead of www.sitename.com/_layouts/appname/
I tried created creating a new web site within IIS that points directly to the app in the LAYOUTS folder. That failed because I was no longer within the SP Context.
I also tried an IIS redirect which worked, but the URL still switched over to the ugly URL.
Does anyone have any ideas for this?
My orginal problem was not being able to detect the currently logged in user for SharePoint outside of SP, so if you have a solution to that problem, that would be great too.
Your best option is to rewrite the URLs and HTML with a proxy. Apache with the mod_rewrite and mod_html_rewrite options are an option. However this kind of setup is not trivial.
You can use URL rewriting in IIS.
I'm now reading some introduction materials about OAuth, having the idea to use it in a free software.
And I read this:
The consumer secret must never be
revealed to anyone. DO NOT include it
in any requests, show it in any code
samples (including open source) or in
any way reveal it.
If I am writing a free client for a specific website using OAuth, then I have to include the consumer secret in the source code, otherwise making from source would make the software unusable. However, as it is said, the secret should not be release along with the source.
I completely understand the security considerations, but, how can I solve this dilemma, and use OAuth in free software?
I thought of using an external website as a proxy for authentication, but this is very much complicated. Do you have better ideas?
Edit:
Some clients like Gwibber also use OAuth, but I haven't checked its code.
I'm not sure I get the problem, can't you develop the code as open source retrieve the customer secret from a configuration file or maybe leave it in a special table in the database? That way the code will not contain the customer secret (and as such will be "shareable" as open source), but the customer secret will still be accessible to the application.
Maybe having some more details on the intended platform would help, as in some (I'm thinking tomcat right now) parameters such as this one can be included in server configuration files.
If it's PHP, I know a case of an open source project (Moodle), that keeps a php (config.php) file containing definitions of all important configurations, and references this file from all pages to get the definition. It is the responsibility of the administrator to complete the contents of this file with the values particular to that installation. In fact, if the application sees that the file is missing (usually on the first access to the site) it will redirect to a wizard where the administrator can fill the contents in a more user friendly way. In this case the customer secret will be one of these configurations, and as such will be present in the "production" code, but not in the "distributable" form of the code.
I personally like the idea of storing that value in the database in a table designed for it and possibly other parameters as the code needs not be changed. Maybe a installation wizard can be presented here ass well in the case the values do not exist.
Does this solve your problem?
If your service provider is a webapp, your server needs consumer signup pages that provides the consumer secret as the user signs up their consumer. This is the same process Twitter applications go through. Try signing up there and look at their workflow, you'll have all the steps.
If your software is peer-to-peer, each application needs to be both a service provider and a consumer. The Jira and Confluence use cases below outline that instance.
In one of my comments, I mention https://twitter.com/apps/new as the location of where Twitter app developers generate a consumer secret. How you would make such a page depends on the system architecture. If all the consumers will be talking to one server, that one server will have to have a page like https://twitter.com/apps/new. If there are multiple servers (i.e. federations of clients), each federation will need one server with this page.
Another example to consider is how Atlassian apps use OAuth. They are peer-to-peer. Setting up Jira and Confluence to talk to one another still has a setup page in each app, but it is nowhere near as complex as https://twitter.com/apps/new. Both apps are consumers and service providers at the same time. Visiting the setup in each app allows that app to be set up as a service provider with a one-way trust on the other app, as consumer. To make a two-way trust, the user must visit both app's service provider setup page and tell it the URL of the other app.