Why does rich hover in RQM repeatedly asks for OAuth authentication?
Mattias Berglund (56●1●1●1)
| asked Aug 19 '11, 7:28 a.m.
edited Jul 03 '12, 9:16 a.m. by Geoffrey Clemm (30.1k●3●30●35)
Hi,
We have made a rich hover implementation in a system (let's call it X). To view this web page , the user has to be logged on using Basic authentication. In RTC, the rich hover works fine. When hovering over the link, I get a basic authentication login (if I'm not already logged on to the other system) and after login, I can see the small and large preview pages. However, in RQM we have a problem. When hovering over the link, we get a text "Log in to X to view this content". If I click on Log in, I get the basic authentication and then I'm sent to the OAuth authentication page for X. After authenticating the connection, this page is closed and I hover over the link again. This time I'm directly sent to the OAuth authentication page for X. This one, I don't need to do anything about, just close the page and after this the hover function works. If I have more than one link, the second authorization page shows up once for each link. So first of all, why is OAuth at all involved in this? The rich hover should, as far as I see it, be strictly client side? It works this way in RTC at least. The script for fetching the compact rendering XML (using application/x-jazz-compact-rendering accept header) is, of course, done on server side but this one is not password protected, so no OAuth should be necessary for this either. Second; If RQM requires some server side communication using OAUth, why do I get the second authorization page that does nothing? We have tried using both Firefox 3.6 and IE 8 and the behavior is the same. Best regards, Mattias |
13 answers
Hi Mattias,
RTC and RQM actually use the same underlying widget to show rich hovers, so the functionality should not be different from product to product. Are they both similar versions (and therefore running the same or similar versions of the Jazz Foundation code)? What version is each product? The reason OAuth is involved is that that is how our proxy works to allow communications with friend servers. Because your server is on a different domain (or could be), we are forced to use a server side proxy to fetch the compact rendering document. OAuth is the authorization mechanism that our proxy uses to facilitate cross server communications and when you setup the friend linkage to your server (which you must have done for the rich hovers to be functioning) you would have had to establish a consumer key and secret for OAuth. Why you are not seeing the OAuth prompt in RTC, but you are in RQM is a bit of mystery, as is why you are seeing it twice in RQM. Do you know if all apps have your server listed as a "Trusted" application? This could be the difference of why the OAuth prompt is shown only for RQM. |
|
Thanks for clarifying the reason for OAuth a bit. Though I still don't understand why the proxy has to use OAuth to fetch a page that is not password protected at all. ;-)
Anyway, a good idea with the "Trusted" flag. I have now tried to remove the friend and added it again, making sure it is trusted. I had to authorize the connection to our application but after this I still get the authorization page when hovering. I can also add that the rich hover page actually shows up for a short while before the second (unnecessary) authorization pops up. When it comes to versions, This is the information from RQM: Jazz Foundation - Jazz Team Server 1.0.0.2 iFix 6 (I20110128-1600) Rational Quality Manager 2.0.1.1 iFix 3 (I20110418_0858) Change and Configuration Management - Core Libraries 3.0 RTC-I20101112-1731 Jazz Foundation - Core Libraries 3.0 RJF-I20101112-0630 So we actually have a mismatch between the Jazz foundation version in RTC and RQM. I will check with the server responsible to see if we can try to change the Foundation code so that they are the same and try to see if it makes any difference. |
|
Ah. That explains a lot. In 1.x Foundation, the proxy was pessimistic. It would force you to do the OAuth dance with the server before it even tried to talk to it. In 3.x, it is optimistic and will only force you to do the dance when it gets a 401 back from the destination. So, the discrepancy in the behaviour makes sense, but why it would be prompting you to approve the OAuth access twice is still a bit of a mystery.
I would say it's probably a bug in the 1.0.0.2 iFix 6, but that code has been around for ages, so that doesn't seem likely. Just to confirm that I'm understanding, after the initial basic auth/oauth approval, you hover the link again and you get a popup showing you the oauth approval prompt again? And this time, simply closing it (not saying yes) lets you interact with the link/rich hover normally? |
|
Now I have finally installed and tested this on RQM 3.0.1 and now this bug disappeared :)
Though another problem occurred. If I'm trying to add a defect from the external system, I can select it and it's visible (and the rich hover works fine). But when I try to save the Execution Result I get an error. First, the message is set to "Saved Successfully". A little popup shows up saying "Assiciate defect" and then an error message pops up with the text "Error: Unable to load /qm/proxy?uri=<URI>%3Foslc_cm.properties%3Dcalm%253AaffectsExecutionResult status:401" (where URI is the web address to our external defect). And after reloading the Execution Result, the external defect is not connected. The external defect system requires user credentials (using Basic Authentication or OAuth) to be able to fetch or update defect information. I might be able to make a fix so that fetching affectsExecutionResult is allowed without providing any credentials, but I made a test with this a while ago for an RTC issue and after this fetch, RTC tried to fetch the complete defect and if this is the case here, I cannot allow that without proper authorization. For our current implementation, we don't need any back-link (this was not done in the older version of RQM) so is it possible to do any of these things: * Configure RQM to do the OAuth dance (or use stored access token) during the save operation . * Configure a project area to not try to update back-link. * Save the Execution Result even if the error occurs. Or do you have any other idea how to solve this? |
(...) Hi Mattias, So far the option I think will better work for you should be your third one: Save the Execution Result even if the error occurs. This behavior was added recently for RQM 3.0.1.1 (Fixpack) in order to avoid problems during the creation/removal of related links which leaded to hang the saving process, which I'm pretty sure will cover the case of saving the Execution Result even when an error creating the backlink occurs. So maybe you can give the fixpack a try and see if this solves your need. |
The fixpack RQM 3.0.1.1 is not yet available, right? Latest available is a milestone relase (3.0.1.1 M3 according to https://jazz.net/downloads/rational-quality-manager) -- do you know if the fix is included in this milestone? Rgs, /N |
(...) Hi Mattias, So far the option I think will better work for you should be your third one: Save the Execution Result even if the error occurs. This behavior was added recently for RQM 3.0.1.1 (Fixpack) in order to avoid problems during the creation/removal of related links which leaded to hang the saving process, which I'm pretty sure will cover the case of saving the Execution Result even when an error creating the backlink occurs. So maybe you can give the fixpack a try and see if this solves your need. I will try this with the M3 and hope it's included. But in the future I think we want to be able to really update a back-link. The other system is (of course) secured. So how is the recommended way to solve this? I thought that this was exactly where OAuth should be in use. |
|
I have now installed 3.0.1.1M3 and it seems like this fix is not included. I still get the error message and the defect is not saved.
|
|
So. Any other ideas how to solve this? Like I said before: The best way to solve this would be if it was possible to update the back-link. So how can this be done? I suppose that it should be possible to do since it works if I connect RQM and RTC so some authentication information should be sent to the connected system when saving.
|
So. Any other ideas how to solve this? Like I said before: The best way to solve this would be if it was possible to update the back-link. So how can this be done? I suppose that it should be possible to do since it works if I connect RQM and RTC so some authentication information should be sent to the connected system when saving. Hi Mattias, Sorry for the slow response. RQM 3.0.1.1 is available now, but I agree updating the back link is the best solution. You need to figure out which HTTP request is returning the 401, and then figure out how to get the web browser authenticated with your server before, or as part of, that request. RQM doesn't do any explicit handling of the authentication. RQM just inherits any cookies that have been set in the session, and also uses the oauth headers from the RQM server. Which means when a request to your Defect Provider is done asking for the whole resource the authentication should be already granted or else the error would prevent the back link to be created/updated. That's how the process works when integrated with RTC. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.