Bug 338596

Comment 1 John Arthorne 2011-03-02 08:50:08 EST

I have now seen this on FF too.

Comment 2 Susan McCourt 2011-03-02 12:37:41 EST

After pulling the latest this morning (my time), I found that refresh didn't even fix me on FF when I tried to use navigate-table.  I logged in, then I refreshed, and still a broken page.  Szymon told me to go to index.html instead, and that worked.

Comment 3 John Arthorne 2011-03-02 13:24:29 EST

(In reply to comment #2)
> After pulling the latest this morning (my time), I found that refresh didn't
> even fix me on FF when I tried to use navigate-table.  I logged in, then I
> refreshed, and still a broken page.  Szymon told me to go to index.html
> instead, and that worked.

Interesting. I just pulled again and I'm not seeing that. Anyway I think I need to block/queue the authentications until the login is complete, which should fix either case.

Comment 4 Malgorzata Janczarska 2011-03-04 08:40:38 EST

The problem is caused by moving fileService to the plugin. Earlier it worked because on each error fileService calls handleAuthenticationError passing the server response. If the error code was 401 the call was added to a queue and the login window was displayed. If user logged in all the calls from queue were renewed.
Now, when the service is in the hidden iframe it may even open the login window, but user will no see it anyway and won't be able to log in.
The login dialog you see sometimes on navigate-table is actually displayed because we are doing an extra call to display the login name on the top-right corner. This is actually a legacy from time when userService was not provided by plugin - it always makes call to the localhost.
If you log in the displayed window you'll have a session and all your future calls are authenticated, but the iframe that contain fileService does not get any notification that you have been authenticated, so it doesn't know that is should renew all the queued calls.
What is more if you loose your session while navigating though navigate-table, the login window won't be redisplayed to you. (you can test it by removing sessionid cookie for Orion server from your browser).

So what can we do for M6 is I think we should:
1. add an even in fileService plugin that notifies navigate-table about invocation errors. If error would be 401 navigate-table would display the login window that it currently has.
2. add a function to fileService plugin that would renew all the calls from the queue
3. when authentication is completed on navigate-table we should call the method from point 2.

This will solve the problem when fileService, usersService and Orion client are on the same host.

In the next step we should somehow allow fileService or userService to display its own login dialog and navigate-table shouldn't have any knowledge of it. But before we do it I think we should rethink the whole concept of authentication, because if we can provide fileService as a plugin, so maybe we could provide two of them? If we authenticate to each of them with different credentials then it will be clearly visible that there is no such a thing as "authentication to Orion". The authentication is in fact to each of Orion plugins/services.

Comment 5 John Arthorne 2011-03-04 12:24:40 EST

I have released a fix for this. There are going to be a number of things that need to be done on the framework side when dealing with the file service: login, retry on 401, authorization, etc. So, the solution I took is to introduce a helper class eclipse.FileClient. This object is used by the navigator, editor, etc, when dealing with the file API. It abstracts away the service call, and authentication/authorization issues. So most client code changes from:

this.serviceRegistry.getService("IFileService").then(function(fileService) {
  fileService.doSomething(args);

The new form is:

fileClient.doSomething(args);

I refactored the existing file implementation into two files:

fileClient.js - the helper object
fileImpls.js - the file implementation used by the file plugin. Clients won't use this directly.

Comment 6 John Arthorne 2011-03-04 12:26:27 EST

(In reply to comment #4)
> before we do it I think we should rethink the whole concept of authentication,
> because if we can provide fileService as a plugin, so maybe we could provide
> two of them? If we authenticate to each of them with different credentials then
> it will be clearly visible that there is no such a thing as "authentication to
> Orion". The authentication is in fact to each of Orion plugins/services.

Yes. We're hoping we can use something like OAuth to delegate limited authority to a plugin to perform an operation on the user's behalf. So the user would continue to authenticate directly to Orion, and we would manage the delegated authorization for plugins. This is something Simon is planning to explore in M7.

Comment 7 Szymon Brandys 2011-03-08 09:11:47 EST

I'm not sure what happened, but it looks even worse now. The login dialog does not appear at all. If I log in using the FireBug console (using login();) and sign out using the 'Sign Out' action from the User menu, the User menu disappears. I can see it on three different machines.