WE apps using Password Managers?

Targets Web
1

This may be a silly question, but is there a way to get WE apps working with popular password managers in browsers? For example, I use LastPass to help manage website/app logins and it doesn’t recognize that I’ve logged in.

2

The biggest problem I see is that WE doesn’t let you have sane id attributes on your input elements, it makes up random ones. This means password managers can’t find the username/email/password fields when you return to the site as the input ids have changed.

Is this related to your problem Bob?

3

Probably. I know they do that on purpose and in fact I would call it a security ‘feature’ as it makes it harder for some man-in-the-browser and man-in-the-middle sniffing.

Just wondering if there’s a way to override the functionality.

4

[quote=11863:@Bob Keeney]Probably. I know they do that on purpose and in fact I would call it a security ‘feature’ as it makes it harder for some man-in-the-browser and man-in-the-middle sniffing.

Just wondering if there’s a way to override the functionality.[/quote]

or override it on “certain fields” so the password managers would work.

5

Bob, Thinking out loud… You could put your login form in an

6

That’s a thought. Have to bang on that for a while. It’s so low on the priority list I probably won’t revisit for months but thought I might find an ‘easy’ answer. Thanks!

7

@Bob Keeney

I’m surprised this doesn’t work actually. We specifically set the Name attribute on native controls so they’ll still work.

8

I’m wondering if it’s because we’re not using ‘Name’ and ‘Password’ for the fields.

9

Last year sometime I asked about password managers and WE apps. I too use LastPass and it wasn’t working. I believe Thom stated that 1Password was working for him, and that he might look into LastPass. I guess he never got around to it (understandably).

Anyway, Greg’s comment above got me thinking, so I first verified that the Name attribute did indeed match my control name. Then I created a manual site entry in LastPass for my WE app, including adding form fields that matched my control names, which would be the value in the Name attribute. LastPass still doesn’t recognize when I’m on the login page (maybe because I actually use a dialog for the login - and I’ve had trouble with LastPass on other sites that do the same). But, I can click the LastPass toolbar icon and my site entry is there. I can choose it and select AutoFill and it successfully fills in the login information. So that’s getting somewhere, but it won’t work automatically.

After some more tinkering it appears that LastPass doesn’t use the Name attribute for auto-recognizing the login fields. It seems to rely on the id. If you bring up your login screen in your WE app and fill in your login information, but don’t login, then go to LastPass and choose Save All Entered Data, you will see that it is using the id attributes.

I have used 1Password in the past. I may have to try it again to see how it fares.

10

I’m using RoboForm on OSX and Windows and for me it works well, with a WE Login form, where I’m using a password textfield.

11

I’ve done a little digging abut this.

Password managers like 1Password rely on the HTML Tag to know which fields it should be capturing, that being the type of form where when you press Submit, it sends your username and password as part of the request that tells the server where to direct you to next.

That being said, there’s no reason that someone couldn’t create a login control using the WebSDK that would obey the rules. The downside (since you still don’t “Submit” data to the server) is that you may need to explicitly tell 1Password to record the data.

12

Thanks Greg. I may look into that. I had thought about trying a WebHTMLView for the login form, as Brad mentioned, but using the WebSDK would probably work even better. It may be a while before I can get to this, so if anyone else creates one they could share, I would appreciate it (and probably many others also). Or Brad, you could add one to your Web Essentials! :wink:

13

I’ve done a little research on this… The password managers built into browsers commonly look at the DOM when the page loads, so that flat-out may not work with WE apps. Additionally, Firefox seems to be sensitive about autofilling a form in a contained frame.

A workaround that comes to mind… And I’m 90% sure this is more complicated than it has to be, so please refine it…

1. At start of new session, redirect browser to a “special” URL to display login form as simple HTML form, POST data back to main URL of app.
2. User submits form, new session starts. That session sees the POST data, logs user in.
Make sense?

This requires a login cookie:

  1. When a session is started, check for the login cookie. If it exists and is valid, carry on to logged in mode.
  2. If cookie doesn’t exist, show a “special” page with a login form.
  3. The form action is another “special” page to validate the login.
  4. If the login is validated, a cookie is set, and browser redirected to main app page (see 1).
  5. You’ll need a session cookie table to keep track of the cookies, and if they are single session or semi-permanent.
14

I created a sample for what I described above and included it in a maintenance release of Web Essentials:

http://www.studiostable.com/webessentials

An email went out to current licensees so they can grab the update.