[troyb]

Originally Posted by Nat

I think you should work a lot on the form fill code.
OW doesn't work also if you have different password form on different URI of the same site.

This is actually for security reasons. We used to only check the domain but decided to stop doing this once potential security holes were pointed out.

[Bob Williams]

Unfortunately, a lot of sites, especially those of major companies, tend to have constantly changing URLs, which presents a problem with OW. On these sites, it's not unusual to see both the 3rd-level domain and the file path change.

I even seem to remember this creating the effect on one or two sites of having multiple username/password combinations stored in the keychain by OW, with the end-effect being that multiple loads of the same page end up with a different login pre-filled each time depending on which server happens to handle your request.

[Nat]

Originally Posted by troyb

This is actually for security reasons. We used to only check the domain but decided to stop doing this once potential security holes were pointed out.

Which are the security issues ?
The latest Safari save everything without problems :)

[troyb]

Actually, to my knowledge we behave the same way that Safari and Firefox do. We pay attention to the full domain (including 3rd ,2nd and 1st levels) I don't think the rest of the URL matters.

If you have examples that work in those browsers but don't in OmniWeb feel free to point me at them.

[Nat]

Originally Posted by troyb

Actually, to my knowledge we behave the same way that Safari and Firefox do. We pay attention to the full domain (including 3rd ,2nd and 1st levels) I don't think the rest of the URL matters.

If you have examples that work in those browsers but don't in OmniWeb feel free to point me at them.

I'm sorry but they are internal sites (and the site is SSLed)...
However if should simply to reproduce...
You just need to have two forms on two different folder of the same site which need two different username & password to login.
For example:
www.omnigroup.com/app1 with username1 & password1
www.omnigroup.com/app2 with username2 & password2

[Forrest]

I have two gmail accounts. I tried them both in SP17 and Safari. SP17 reacted just like Safari.

[Nat]

Originally Posted by Forrest

I have two gmail accounts. I tried them both in SP17 and Safari. SP17 reacted just like Safari.

The problem is when you use two different account on two different forms on the same site and not if you use two different account on the same form

Moreover i think that safari can handle multiple username/password on the same form while OW doesn't

[troyb]

Originally Posted by Nat

www.omnigroup.com/app1 with username1 & password1
www.omnigroup.com/app2 with username2 & password2

I think I may have been getting carried away. The issue you're reporting above, being able to save two passwords for a single site -- what you initially reported -- is something we hope to add in the future.

The issue that I'm rambling on about is where:

https://login.omnigroup.com -and-
http://anothersite.omnigroup.com

share passwords with each other. This wont work in OmniWeb, you'll have to save passwords for each site separately.

[Bob Williams]

Closely related, it'd be nice if, every time, we *could* save login information.

I know with one of the recent releases, OW added support for the HTML form property that tells it not to save form logins. (I forget what it is - I never use it because I believe in leaving control in users' hands.) Is there any way to get it to *not* honor that property? My computers are all properly secured, so there's no reason for me not to have the convenience of autofilled logins just because there are users out there who need to be protected from themselves.

[afb]

Originally Posted by Bob Williams

Closely related, it'd be nice if, every time, we *could* save login information.

I know with one of the recent releases, OW added support for the HTML form property that tells it not to save form logins. (I forget what it is - I never use it because I believe in leaving control in users' hands.) Is there any way to get it to *not* honor that property? My computers are all properly secured, so there's no reason for me not to have the convenience of autofilled logins just because there are users out there who need to be protected from themselves.

Perhaps this bookmarklet will work in OW to allow you to do this; haven't tried it recently though (and I don't really remember if it ever worked in OW).

javascript:(function(){var ca,cea,cs,df,dfe,i,j,x,y;function n(i,what){return i+" "+what+((i==1)?"":"s")}ca=cea=cs=0;df=document.forms;for(i=0;i<df.length;++i){x=df[i];dfe=x.elements;if(x.onsubmit){x.onsubmit="";++cs;}if(x.attributes["autocomplete"]){x.attributes["autocomplete"].value="on";++ca;}for(j=0;j<dfe.length;++j){y=dfe[j];if(y.attributes["autocomplete"]){y.attributes["autocomplete"].value="on";++cea;}}}alert("Removed autocomplete=off from "+n(ca,"form")+" and from "+n(cea,"form element")+", and removed onsubmit from "+n(cs,"form")+". After you type your password and submit the form, the browser will offer to remember your password.")})();