Community
Participate
Working Groups
Browser authentication needs to be handled (invisibly). Currently if a site is protected with http authentication the UpdateManagerAuthenticator is used to retrieve http auth credentials (which we already have in the task repository settings page). If the bugzilla instance requires logon the browser will present a bugzilla authentication page (but we are already authenticated via BugzillaClient). For http auth perhaps we can set the necessary connection parameters on the connection used by the browser widget? For bugzilla maybe we could pass the authentication cookies we already have from BugzillaClient on to the browser widget?
*** Bug 171764 has been marked as a duplicate of this bug. ***
I have some ideas how this can be implemented. If someone want to investigate this, please contact me.
*** Bug 173842 has been marked as a duplicate of this bug. ***
*** Bug 184402 has been marked as a duplicate of this bug. ***
In bug 184402 I was wondering if this could be done non-explicitly. What I mean is that just the session (cookie) information of the browser widget might be captured on close and later restored when issue from same repository is opened. So not explicitly setting any credentials in username/password form, rather just keep cookie session alive?
Same story. As far as I know, browser widget don't have an api to set anything like that.
Shouldn't the issue be reassigned from Mylar to platform/ browser widget owners? Would really like to see this- otherwise web connector usage is kind of tedious.. Thanks, Andi
Good point. Please do feel free to file a new bug against Platform on this and make this one depend on it.
Will do. Did a little checking first. Even if hacky- would this help? http://www.sagewire.org/swt-platform-eclipse/Browserexecute-failure-306849.aspx
execute() doesn't return data... Opened bug 187315- please update depends on field. Thanks.
Thanks Andreas. We have to leave this as helpwanted for 2.0, but may be able to look at a patch. I've seen this approach used before and we would also have to make sure that it is robust across platforms because I think I recall seeing it fail with Safari as the embedded browser.
From bug 187315 1) open browser at web repository url; use addProgressListener(ProgressListener) to get notified about load finished. Widget might be invisble at that time 2) use execute() to set the cookies using javascript setCookie(), check http://techpatterns.com/downloads/javascript_cookies.php 3) repeat step 1), widget is visible now 4) user does whatever- we'll need to listen for widget destruction or navigation events through ProgressListener 5) if widget is closed or navigated, we use execute() again to get the current cookies and associate them with the repository
From bug 187315 Btw this is not only needed for web connector, but for all connectors- e.g. bugzilla when voting.
Mik, regarding comment 11, could you point me to where you've seen this before? Better use best practice than reinvent the wheel..
I was referring to what Grant Gayed linked in comment#1 of bug 187315.
*** Bug 202753 has been marked as a duplicate of this bug. ***
Eugene: this is not a good candidate for bugday because the solution for this likely needs to be browser or OS specific, and as such is out of the current scope of Mylyn. However, leaving open and helpwanted in case SWT enables a more generic solution.
(In reply to comment #17) > Eugene: this is not a good candidate for bugday because the solution for this > likely needs to be browser or OS specific, and as such is out of the current > scope of Mylyn. However, leaving open and helpwanted in case SWT enables a > more generic solution. Solution suggested by SWT guys that is outlined in comment #12 doesn't seem like browser or OS specific.
(In reply to comment #18) > Solution suggested by SWT guys that is outlined in comment #12 doesn't seem like > browser or OS specific. Shawn: do you know if that approach works across browsers, or does that style of Javascript invocation typically require MSIE/Mozilla specific coding and Browser access?
That approach should work across browsers, but there are some incompatibilities with JS on MAC and Linux, so some more testing would be needed to ensure that this method would work.
Any chance revisting this for next release? Only thing preventing me from using Mylyn for sf.net and others...
I've filed a request for an alternate approach to this on bug 223760.
Andreas: our current focus is the Tasks framework and support rich connectors and as Ketan points out this improvement would be best made to the SWT browser widget.
Ketan, seeing that bug 223760 has been resolved- have you by chance been able to try this approach? If not I'd volunteer to test with SF as sample app.
Raising priority. It would be nice to have this in order to avoid the need to log in.
I've spent some time looking into this and believe there might at least two more or less complex scenarios at hand: 1) The repository supports some form of authentication like BASIC or similar. I'm not sure this is already handled by the code, but in this scenario the OpenWithBrowserAction and openUrl methods would need to be enhanced to a) retrieve the credentials from the repository and b) add an authentication listener to the browser 2) Most web sites will set cookies to recognize returning users. This could easily be supported by the new set/getCookie API in swt.browser. The cookie (or rather- all cookies) should be stored as repository parameters (there is such a thing, is there?) and initially set when opening the browser and retrieved each time browser navigation is finished using a progresslistener. In each case, I'm stuck at the point where I need to obtain an swt.browser, as the WorkbenchUtil only provides IWorkbenchBrowserSupport. Is there any chance to get one from the other?
Rob, Steffen: How hard is this? I wonder if we should consider it for 3.3.
This would require some work for Trac and JIRA since we currently don't provide access to the login cookie. By default Trac doesn't need one since it authenticates for each request so it would have to explicitly login before opening the browser. JIRA logs out after each request invalidating the cookie (bug 277405).
*** Bug 269541 has been marked as a duplicate of this bug. ***
As per today's discussion, this will be a bit tricky due to needing to maintaining 3.4 support so it will require an up-front design discussion, but it would be very valuable to have.
Is there a timetable for fixing this bug? This is a serious usability issue...
This is indeed annoying and is a great candidate for community contribution. I'm tentatively going to put it on the 3.5 plan but it may only get done if someone out there is feeling motivated.
Which browsers and versions does this apply to?
The embedded browser, ie, as of Eclipse 3.5 you should be able to set the credentials directly on SWT's Browser widget. If I recally correctly. Steffen? Shawn?
The issue in reproducible in 3.6.2 and 3.7.0: the credentials are requested to be entered/confirmed in Internal Browser's sub-window. I expect that the setting repository credentials will be used for connecting URL without any additional UI.
Sorry, I meant 3.5.2 and 3.6.0
I am pretty sure that the API was added in 3.5.0 (Both for cookies and authentication). Since we still support 3.4.x, this will make it a bit more difficult, but should be doable.
We don't officially support Eclipse 3.4 any longer. The summary of this bug indicates that the API was added in Eclipse 3.5 so it should be feasible to implement this now.
Steffen: Let's consider this for 3.6. Tentatively adding to plan.
I cancel my vote - the credentials can be passed via overriding AbstractRepositoryConnector#getAuthenticatedUrl() or calling addAuthenticationListener() of SWT Browser.
(In reply to comment #40) > I cancel my vote - the credentials can be passed via overriding > AbstractRepositoryConnector#getAuthenticatedUrl() or calling > addAuthenticationListener() of SWT Browser. Well, the first one is a valid workaround for connectors which implement a url-based authentication scheme, which is not always true. As for the Browser-based workaround, where in the Mylyn API have you find a way to access the underlying browser widget?
(In reply to comment #41) > Well, the first one is a valid workaround for connectors which implement a > url-based authentication scheme, which is not always true. > > As for the Browser-based workaround, where in the Mylyn API have you find a way > to access the underlying browser widget? I use an url-based authentication scheme in the mainstream. Browser-based workaround requires replacing the Mylyn command action, actually it means eliminating use of Mylyn API for opening the task in browser.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
