Bug 311144 - Support for browsers password manager
Summary: Support for browsers password manager
Status: ASSIGNED
Alias: None
Product: RAP
Classification: RT
Component: RWT (show other bugs)
Version: 1.3   Edit
Hardware: All All
: P3 enhancement with 6 votes (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-30 04:52 EDT by Lars Fischer CLA
Modified: 2010-09-03 05:13 EDT (History)
1 user (show)

See Also:


Attachments
First idea of a Javascript based form submit (1.15 KB, text/html)
2010-07-08 16:55 EDT, Ralf Zahn CLA
no flags Details
Second idea of a Javascript based form submit (2.05 KB, text/html)
2010-07-08 16:59 EDT, Ralf Zahn CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lars Fischer CLA 2010-04-30 04:52:02 EDT
Build Identifier: 1.3

Many web applications use an authentication with a login/password dialog. It's a common feature, that these parameters can be stored in the browsers password manager to enable an automatic fill on the next session start.
A RAP login screen based on shell/dialog/form is currently not recognized by these password managers.
It would be nice if there is a feature or how-to documentation to enable RAP users to store and autofill login parameters in the browser.

Reproducible: Always
Comment 1 Ivan Furnadjiev CLA 2010-07-02 04:38:41 EDT
I spent some time, searching for a written spec/rule how browsers recognize the username/password fields. And I didn't find such. In order to trigger the browser password manager we need (based on tests only):
1. A <form> element
2. An <input type="password"> element - this is the password field
3. An <input type="text"> element before the password element. If we have more than one input element before the password one the closest one is used for the username.
I didn't find a way to trigger the browser password manager with a simple "tagging" (name, id or other attribute) of the input element.
Comment 2 Ivan Furnadjiev CLA 2010-07-02 05:10:57 EDT
I forgot one important requirement: the enabled autocomplete is needed for both username and password input elements.
Comment 3 Ralf Zahn CLA 2010-07-08 14:45:37 EDT
The implementation of this feature seems to be very difficult, because 
 - there is no form or submit button in the SWT API
 - the user's input in the text/password field might be sent to the server before the user pushes the submit button (e.g. the password manager could get active although the user only resizes the window)
 - this is only a RAP feature that is not available in RCP, so this is not part of single-sourcing

Maybe this could be a strategy:
 - The programmer creates some UI and defines one text field and one password field to be username/password combinations and a button to be a submit button.
 - (Maybe we could find this out automatically by searching a Composite for the text fields)
 - Within the browser, a form is rendered, but made unvisible.
 - When the user clicks the submit button, the hidden form is submitted (to a dummy servlet that only sends back an empty response). The password maangers gets active.
 - When reopening the page in the browser, the hidden form fields get filled, and some JS reads out their values and puts them to the text fields of the visible UI.

For this, I should clarify, if a password manager gets active when
 - a hidden form is submitted
 - a form is submitted using JS

Some comments for this strategy?
Comment 4 Ralf Zahn CLA 2010-07-08 16:55:28 EDT
Created attachment 173816 [details]
First idea of a Javascript based form submit

The first attachment is a demo of a form that is sent using Javascript. The visible fields could be the text fields in the RAP ui that are not embedded within a form. The hidden form is updated and sent when clicking the button. The disturbing point here is that the page is refreshed when sending the form to a URL.
Comment 5 Ralf Zahn CLA 2010-07-08 16:59:46 EDT
Created attachment 173817 [details]
Second idea of a Javascript based form submit

So I embedded the form into an IFrame. Try it out - it does not work like the default behaviour of HTML forms.
 - the hidden form is sent to the current URL, sending it again does not work (just a problem of this demo)
 - we do not have any suggestions
 - when entering and saving more than 1 credential, the password cannot be set by the password manager

Any ideas?
Comment 6 Ivan Furnadjiev CLA 2010-07-09 01:43:51 EDT
Hi Ralf, your strategy looks good for me. Creating a standalone HTML page that trigger the browser password manager is a good idea. This will prove you strategy and give you a way to test it in all supported by RAP browsers before embed it in RAP. There is a way to not submit the form at all - <form onsubmit="return false;">, but I'm not sure if this will trigger the password manager at all. My idea was the same - embed the form in a iframe to avoid page load.
Comment 7 Ralf Zahn CLA 2010-09-03 05:13:33 EDT
No, the passwort manager does not get active when cancelling submitting the form.
I gues we should think about this feature. We want to have a desktop application in the browser. Desktop applications do not know a browser password manager. Other custom implementations (e.g. using cookies) have their disadvantages (saving passwords in a cookie).
Would it be possible to use Equinox Security to store credentials assigned to a client IP address? No - this would be a security hole when multiple users use different profiles on the same machine.

So we can implement the feature using sample #2, but this would only work if there is not more than one credential available.
A special scenario would be that the user starts with a single HTML page that sends the login form to the server, as a request parameter to the entry point of the RAP application. For this, we do not have to implement any feature.