Community
Participate
Working Groups
Before loading any page Orion consults preference service for a list of plugins. The page won't load until the plugin list is retrieved. If user was't logged in it resulted in empty page and a login popup. The page wasn't loaded until user authenticated. But with bug 355396 we would like to remove the popup and create a dialog that would be a part of the page. Bug the dialog doesn't show because the page is not shown and we have a deadlock. This applies only for the first Orion loading because preference service caches preferences in localStorage and the next time even if user is not logged in he gets the list of plugins from localStorage (this I think is bug 340964). I already added a walkaround for it (see preferences.js#UserPreferencesProvider.prototype.get method). For "/plugins" preference if user is not authenticated I handle it as any other error returning empty plugin list. I needed it to go further with bug 355396, but I generally think it should be redesigned, because: 1. Preventing loading the js client until user logs in break assumption that we authenticate only services not the js client 2. Local plugins are so integral part of the client that I can imagine that some of the are needed in other places before user logs in 3. We have a conflict: local preferenecs vs client-specyfic content. I logged in on a browser, some of the plugins were installed locally from my preferenes, then I log out but plugins stay in the localStorage. Somebody else logs in and he has my configuration and my plugins installed. Probably he won't even have access to some of them (for instance my webdav). To reproduce: 1. Revert my change in preference.js 2. Log out from orion 3. type localStorage.clear() in javascript console 4. reload the page
I've checked in a fix so that now all preference requests blocked by a 401 will return early and get updated in the background once the user has authenticated. There is also work to separate the caching of default vs. local vs. user preferences but the remainder will be covered in bug 340964. John reviewed the current change with me. I'd like this fix in the current build as it's a precursor to work in bug 340964 and although we've done local testing would like to make sure we're not breaking anything with different timing circumstances when running on orion.eclipse.org.
