[xwiki-devs] Bug in MyFormAuthenticator? How should securityfilter work?
Hi, I think I found a bug in MyFormAuthenticator. In line 147 remember me is set to "false" if it is not checked on the login page: rememberme = (rememberme == null) ? "false" : rememberme; But the method processLogin() expects it to be NULL if the user doesn't want to use the remember feature (line 178-187): if (this.persistentLoginManager != null) { // did the user request that their login be persistent? if (rememberme != null) { // remember login this.persistentLoginManager.rememberLogin(request, response, username, password); } else { // forget login this.persistentLoginManager.forgetLogin(request, response); } } The problem is that if I fix this bug by removing line 147 the login process doesn't work anymore! I discovered this while I was implementing OpenID authentication support. I tried to debug it now two days but I didn't succed. The same problem occurs with my OpenID implementation. I'm need to tell XWiki that user xy was logged in and tried to do that by setting the user principal in the request object request.setUserPrincipal(principal); but it doesn't work. Is there some documentation about securityfilter available somewhere? I looked on securityfilter.sourceforge.net and googled for it but I didn't found anything. My next question is how I can add a "openid_identifier" property to the XWikiUsers class as a "XClass" as proposed by Sergiu:
I wouldn't add a new property to the XWikiUsers class; this leads to very thick classes, like XWikiPreferences, with properties used only in specific cases. I'd rather add a new XClass, for example XWiki.OpenIdAccount, and user profiles will have this kind of objects attached.
I didn't found any information on that. How is that done? How can I then search for the user with a specific OpenID identifier? Thank you very much, Markus
I think I found a bug in MyFormAuthenticator. In line 147 remember me is set to "false" if it is not checked on the login page:
OK, now I understand it.. it isn't a bug but the PersistentLoginManager is also used just for session cookies..Kind of misleading naming and variable values (rememberme = "false"). I'm my opinion that's kind of a security flaw. The password is send with each request to the server. That shouldn't happen. OK, it's encrypted and the key can be changed in xwiki.cfg but who does that!? Or is that key generated somehow randomly? I didn't looked into that. Another weakness is that passwords are stored in clear-text in the DB. That's normally considered as a no-go. Only password hashes (with salts) should be stored in the DB. Anyway, the current scheme is causes problems for authentication methods where no password is involved, like in OpenID. How should I address that? The simplest thing would be to automatically create a (random) password for those accounts. Otherwise I think I'll have to change quite a lot. My other question is still open :-) ------%<----------------------- My next question is how I can add a "openid_identifier" property to the XWikiUsers class as a "XClass" as proposed by Sergiu:
I wouldn't add a new property to the XWikiUsers class; this leads to very thick classes, like XWikiPreferences, with properties used only in specific cases. I'd rather add a new XClass, for example XWiki.OpenIdAccount, and user profiles will have this kind of objects attached.
I didn't found any information on that. How is that done? How can I then search for the user with a specific OpenID identifier?
Hi Markus, On Fri, Jul 18, 2008 at 5:54 PM, Markus Lanthaler <[email protected]> wrote:
I think I found a bug in MyFormAuthenticator. In line 147 remember me is set to "false" if it is not checked on the login page:
OK, now I understand it.. it isn't a bug but the PersistentLoginManager is also used just for session cookies..Kind of misleading naming and variable values (rememberme = "false").
I'm my opinion that's kind of a security flaw. The password is send with each request to the server. That shouldn't happen. OK, it's encrypted and the key can be changed in xwiki.cfg but who does that!? Or is that key generated somehow randomly? I didn't looked into that.
Yes this has been detailed by Raffaello, we are trying to find some solution for it.
Another weakness is that passwords are stored in clear-text in the DB. That's normally considered as a no-go. Only password hashes (with salts) should be stored in the DB.
Anyway, the current scheme is causes problems for authentication methods where no password is involved, like in OpenID. How should I address that? The simplest thing would be to automatically create a (random) password for those accounts. Otherwise I think I'll have to change quite a lot.
Seems a very big refactor so I doubt it's feasible for this OpenID GSOC. I don't see anything else than the random password you propose if we don't refactor the whole process. So it's ok for me. Maybe someone has any other idea ?
My other question is still open :-)
------%<-----------------------
My next question is how I can add a "openid_identifier" property to the XWikiUsers class as a "XClass" as proposed by Sergiu:
I wouldn't add a new property to the XWikiUsers class; this leads to very thick classes, like XWikiPreferences, with properties used only in specific cases. I'd rather add a new XClass, for example XWiki.OpenIdAccount, and user profiles will have this kind of objects attached.
I didn't found any information on that. How is that done? How can I then search for the user with a specific OpenID identifier?
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (2)
-
Markus Lanthaler -
Thomas Mortagne