Currently when protocols need to authenticate with a server (http, ftp) they always either ask for a password or require one to be passed in a url. We should instead ask wallet if there's a stored password and use that instead. Right now, we use the nsIPrompt interface to put up password dialogs. This is implemented by the webshell. It seems that there should be some other event sink that we ask for that first queries wallet, and if this fails, then put up the dialog.

You mean single-signon and not wallet. But it does use single signon. It was one of the first customers of single signon when ss was first implemented. Try it and you'll see.

I think there was a little bit of confusion here, after talking to steve I figured out that our call to nsIPrompt is intercepted by single signon and appropriately returned with the right values. And then if single-signon doesn't have the right values, it displays that user/password box. So we are in that sense using single-signon. We could theoretically argue to share the authentication lists at some stage but the single-signon is persistent across sessions and http's (or ftp's) is only built per session. Secondly someone may not have installed single-signon but would still like to use HTTP/FTP's authentication. Hope this clarifies.

Gagan: I don't understand your comment. How does http or ftp supply its own authentication list? If you call the nsIPrompt event sink, and single sign-on implements it, then where do you get a chance to supply a protocol-specific list? Also, how do we specify what we're looking for w.r.t. username/password? nsIPrompt::promptUsernameAndPassword only passes a string -- is this used as a key somehow? I would think the authentication criterion for a protocol would be based on protocol, host, port and username, i.e. I might have a different password for http://warren@foo:80/ vs. ftp://warren@foo:21/.

HTTP/FTP do not supply the list. We walk them before using the nsIPrompt. I am not aware of the details of where and how single signon plugs in nsIPrompt, but I am sure it must also be using the protocol scheme as a key for storing the passwords. So here is what my understanding looks in a more schematic manner- ,----------. ,-----------. These two lists are | HTTP | | FTP | non-persistent and only | authlist | | authlist | per session. '----+-----' '----+------' | | Called thru nsIPrompt +----------------------+ | Single Signon list | This list hopefully uses '----------+-----------' the scheme as key as well (steve?) | ,------+------. | Auth Dialog | Presented finally when single '-------------' signon doesn't have the entry.

Nope, single signon doesn't store the schema -- only the hostname. So if you have saved a login for http://warren@myhost.com and another for ftp://warren@myhost.com, there will be a confusion. Single signon is a heuristic that should work correctly *most* of the time but not *all* the time. If you think this is a serious problem, we should talk more about it.

I think 2 things should happen here: First, our protocol implementations shouldn't be storing their own lists. Single sign-on should be the only repository for logon information. Second, single sign-on should allow an arbitrary key to be used to look up a password, not just a hostname. Usually the key will be the hostname, but in the protocol case, it could be the <protocol, hostname, username, port> tuple. There should be an API that given a key returns a password, that first consults its database, and if that fails, uses a prompt to put up a dialog: boolean getPassword(in wstring key, in string dialogTitle, in wstring promptText, in boolean isPersistent, out wstring password); This should be formulated as an event sink that is implemented by the webshell and the protocols use. The dialogTitle and promptText are the same as in nsIPrompt::promptPassword today. The isPersistent tells single sign-on whether to store the password for the session or perminently. The key is as discussed above.

Let me back off a bit as to what I said before. Single signon normally stores the hostname as I described. But there is a parameter via which you can tell it not to strip the hostname out of the string, but rather use the entire string as the key. So the second item as described in Warren's comment above has already been done. The only thing that isn't there is the isPersistent ability.

I talked to Steve on the phone about this and here's what I got: Single sign-on implements SINGSIGN_PromptPassword which will do the password lookup: extern nsresult SINGSIGN_PromptPassword (const PRUnichar *text, PRUnichar **pwd, const char *urlname, nsIPrompt* dialog, PRBool *returnValue, PRBool strip); The urlname parameter is either parsed (using necko) and the hostname is extracted (via GetHost) if the strip parameter is true. If the strip parameter is false, it is treated as a raw key. We could use this from our protocols using "protocol://user@host:port/" as a key. I'm not sure how this API relates to webshell though. It looks like it takes an nsIPrompt which is the way it puts up a dialog if it needs to. I'm guessing that interface is implemented by the webshell/webshell-window. That seems backwards to me. The thing implementing nsIPrompt in the webshell should be calling SINGSIGN_PromptPassword instead (unless there are 2 objects implementing nsIPrompt here). Furthermore, there's the problem that the nsIPrompt interface doesn't allow the key to be passed which seems wrong. W.r.t. the persistent vs. per-session thing: I'm not sure whether we should _require_ protocol passwords to be only remembered per session. But I guess if we did remember them persistently, we would have to find another means to log off (for user security). I recommend changing a couple of things here: 1. nsIPrompt should implement getPassword as I mentioned above, passing a key 2. the webshell should implement nsIPrompt to call through to SINGSIGN_PromptPassword 3. SINGSIGN_PromptPassword should probably take a boolean persist parameter and only persist the passwords that have had this set (this requires adding a flag to each password struct as its stored in-memory) 4. (extra credit) I'd recommend eliminating the strip parameter from SINGSIGN_PromptPassword too and make the default to never try to strip (i.e. make the caller responsible for the stripping). I don't think single sign-on should depend on necko. Steve says davidm knows about the nsIPrompt stuff -- reassigning to him.

nsINetPrompt is the public interface that you should be using to talk to single sign on. The only thing it doesn't have that warren has requested is the persist flag. If steve implements it in the single sign on calls it is trivial to pass along. I assume none of this is going to degrade the user experience on machines which for various reasons have single sign on disabled?

I'll take this back. I really don't want there to be a nsINetPrompt and a nsIPrompt -- there should just be one thing for this.

One of the main reason I didn't do that was I didn't want to make more work for embedders. I am not sure what ss embeddabiity state is currently and we might just not care. Just remember that you have to pass the interface for putting up dialogs to SS as it is really evil to be using the hidden window hack.

Moving to M17 which is now considered part of beta2.

Putting on [nsbeta2+][6/01] radar. This work must be done by 06/01 or we may pull this for PR2.

Fix checked in. Please give it a try.

verified: NT 2000052408