17 Aug
2007
17 Aug
'07
3:48 a.m.
A small framework to enable external validation plugins to be added and
configured for Pier Login.
I am using this with a plugin (not included yet) which validates the
user/pass against a MYSQL query, then it logs in this user using an
internally defined pier-user (or as I call it a "role") as a template.
Finally I perform a second query to obtain a UserData record, and a
potential invalidation is performed on "any other criteria", such as an
account expiry date.
You add your plugin by subclassing PUExternalValidationPlugin, and
select the plugin to use in the application configuration.
Finally your plugin gets the opportunity to customize the Login Dialog's
descriptions. This enables you to customize the presentation of the
dialog if you add Magritte-ComponentDecoration 's. You should also be
able to add extra fields, though I leave this as an exercise for the reader.
enjoy
Keith
17 Aug
17 Aug
7:12 a.m.
If you are making a framework for this part then one thing to consider
is passwords. Most frameworks leave this up to the user, so the user
does the simplest thing they can: they store plain text passwords.
You can tell these sites because when you forget your password and
press the password recovery link they send you your password directly
(ironically, pgp.com does this too!).
Obviously if the password is stored in plain text, then once your site
is hacked all your user's passwords will be known. This wont make
your users happy. So it would be nice to have some kind of password
object or something that always does some kind of one-way encryption
on the passwords (e.g. using MD5).
It would be nice as well for something to do the whole password
recovery stage as well, since this always works the same: user clicks
a link, gets an email forwarded that points to a secure site where
they can type in a new password, since passwords are not recoverable.
Just something to think about.
On 8/17/07, Keith Hodges <keith_hodges(a)yahoo.co.uk> wrote:
A small framework to enable external validation
plugins to be added and
configured for Pier Login.
I am using this with a plugin (not included yet) which validates the
user/pass against a MYSQL query, then it logs in this user using an
internally defined pier-user (or as I call it a "role") as a template.
Finally I perform a second query to obtain a UserData record, and a
potential invalidation is performed on "any other criteria", such as an
account expiry date.
You add your plugin by subclassing PUExternalValidationPlugin, and
select the plugin to use in the application configuration.
Finally your plugin gets the opportunity to customize the Login Dialog's
descriptions. This enables you to customize the presentation of the
dialog if you add Magritte-ComponentDecoration 's. You should also be
able to add extra fields, though I leave this as an exercise for the reader.
enjoy
Keith
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
7:30 a.m.
So it would be nice to have some kind of password
object or something that always does some kind of one-way encryption
on the passwords (e.g. using MD5).
Pier never stored passwords as plain text. It is using SHA to
generate a hash number that is then stored in the user object.
It would be nice as well for something to do the whole
password
recovery stage as well, since this always works the same: user clicks
a link, gets an email forwarded that points to a secure site where
they can type in a new password, since passwords are not recoverable.
That's easily doable (see for example SqueakSource), the only problem
is that a Pier User doesn't include an e-mail address right now.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
11:03 a.m.
On 8/17/07, Lukas Renggli <renggli(a)iam.unibe.ch> wrote:
Pier never stored passwords as plain text. It is using SHA to
generate a hash number that is then stored in the user object.
Ah good to know. Most things are nice to leave up to the user, but
things like this are so fundamental that it's best if the
default/template is already using good behavior. Nice to hear that
Pier already is. In my mind that is a positive for Pier over many of
these other CMSes.
That's easily doable (see for example
SqueakSource), the only problem
is that a Pier User doesn't include an e-mail address right now.
Lukas
Good point. I was thinking more along the model point of view, something like:
PPaswordManager>>changePassword
self confirmUserWantsChangeElse: [ ^ self ].
passwordHash := self encrypt: (self askPassword).
The model can be displayed by the different schemes, one way would be
to use mail. Or maybe one view would do it directly in the site, not
requiring email.
Maybe we could even use the call:/answer: system to ask the password.
That would probably work whether an HTTP get happens between, or an
email conversation, no? :)
11:32 a.m.
Good point. I was thinking more along the model point
of view,
something like:
PPaswordManager>>changePassword
self confirmUserWantsChangeElse: [ ^ self ].
passwordHash := self encrypt: (self askPassword).
The model can be displayed by the different schemes, one way would be
to use mail. Or maybe one view would do it directly in the site, not
requiring email.
Maybe we could even use the call:/answer: system to ask the password.
That would probably work whether an HTTP get happens between, or an
email conversation, no? :)
What I do and what is very easy to do is to create a secret
continuation key that does the login of the requested user. This URL
is not displayed in the browser, but sent by mail. Clicking on the
URL enables the user to login and to change its password. The
potentially dangerous link eventually expires when Seaside cleans up
the Session.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
8:22 a.m.
Jason Johnson wrote:
If you are making a framework for this part then one
thing to consider
is passwords. Most frameworks leave this up to the user, so the user
does the simplest thing they can: they store plain text passwords.
You can tell these sites because when you forget your password and
press the password recovery link they send you your password directly
(ironically, pgp.com does this too!).
Obviously if the password is stored in plain text, then once your site
is hacked all your user's passwords will be known. This wont make
your users happy. So it would be nice to have some kind of password
object or something that always does some kind of one-way encryption
on the passwords (e.g. using MD5).
It would be nice as well for something to do the whole password
recovery stage as well, since this always works the same: user clicks
a link, gets an email forwarded that points to a secure site where
they can type in a new password, since passwords are not recoverable.
Just something to think about.
Sure! In the interests of minimal configurable components, this bit only
provides the wiring to your supplied plugin.
At present using MySql I am storing the passwords in the db
PASSWORD("blah") format and querying them the same.
However the Cryptography package is capable of generating hash so that
plaintext does not need to be exchanged with the server.
I haven't got to password reminding schemes, or supervised password
resetting yet. I need at least one scheme soon.
thanks for a "requirements statement"
Keith
6095
days inactive
6095
days old
5 comments
3 participants
participants (3)
-
Jason Johnson -
Keith Hodges -
Lukas Renggli