authentication for seaside

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: authentication for seaside

sergio_101-2
oh!

my thoughts on user/password persistence would be just at the image
level. that way, the end user could plumb it any way they would like.

the plugin will provide:

login/register forms
logged in as/log in links

using the forms:
confirm your account functionality
forgot your password functionality
edit your user account functionality

the idea being that a developer could simply import the classes into
the project, and edit as needed.

thanks!

--
----
peace,
sergio
photographer, journalist, visionary

http://www.CodingForHire.com
http://www.coffee-black.com
http://www.painlessfrugality.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: authentication for seaside

tfleig
In reply to this post by sergio_101-2
Hi Sergio,

I am working on just such a package that has the features listed below.

The test application is on-line here:

     http://www.ensurete.com/LoginTestApp

You can turn on and off all the optional features that would normally
be set by the host application using the test app's input form.

Feature list:

      Login component containing the following items
      Username entry
      Password entry
      Login button
      Forgot username button
      Forgot password button
      Register button
      Remember my username on this computer checkbox (optional)
      Log me in automatically when I return to this site checkbox (optional)

   Register component containing the following items:
      Username entry
      Password entry
      Confirm password entry
      Email address
      Recaptcha protection (optional)

   Edit Account Detail component that allows
      Change username
      Change password
      Change email address

   Optional email confirmation of registration and account changes is provided.

   Preferences that can be set by the host application or on the
Seaside config page are:

                'Confirm registrations via email.'.
                'Minutes to wait after sending registration and password reset emails'.
                'Protect registration form against spam with reCAPTCHA'.
                'Outgoing mail server address or sending registration confirmation emails'.
                'Confirm email address changes by sending email to the new address'.
                'Confirm all account changes by sending email to the (possibly new) address'.
                'Allow empty passwords'.
                'Allow users to change their username'.
                'Allow users to remember their username in a cookie'.
                'Allow auto-login using username/password cookies'.
                'Expiration period in days for username and password cookies'.
                'Recaptcha public key - see http://www.google.com/recaptcha';
                'Recaptcha private key - see http://www.google.com/recaptcha';

The user information is persisted using the plug-in pattern. A
ReferenceStream file persistence provider is provided as the default,
but another persistence scheme could be plugged in in its place. There
is an application properties dictionary included in the user object
that is persisted and restored should the host application wish to
make use of it.

The confirmation email content is prepared by the hosting application
through callbacks that provide the essential information needed, e.g.
the URL the user must navigate to to confirm registration, the number
of minutes within which they must do this, etc. Multi-part MIME email
messages (HTML and plain text parts) are included as samples.

My goal was to make this work out-of-the-box if all the defaults were
acceptable, but allow the host application to override and substitute
functionality where needed. Also I tried to minimize dependencies on
outside packages other than Seaside 3.0.

There are a number of things I was hoping to complete before letting
anyone else see it, including refactoring, commenting, encrypting
stored passwords, moving inline styles to a CSS file, and the like.

There are also a number of additional features that I think should be
added, such as security questions for use at public sites and security
images and phrases like banking websites have, but I thought I would
try integrating it into one of my own applications before doing any of
that.

If you are interested in the package in its current form, I can make
an mcz file and send it to you -- probably by tomorrow. Caution is
warranted though, I am still learning Seaside and the code needs a lot
of cleanup -- that's what I'm working on now.

Regards,
TF
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: authentication for seaside

tfleig
Update:

Passwords are not stored any longer in the persistent data store.
Instead, a SHA1 hash of the password and the user's UUID is stored.
(This is to reduce the hazard of the user authentication data store
being compromised.)

TF

On Wed, Dec 29, 2010 at 11:46 AM, Tony Fleig <[hidden email]> wrote:

> Hi Sergio,
>
> I am working on just such a package that has the features listed below.
>
> The test application is on-line here:
>
>     http://www.ensurete.com/LoginTestApp
>
> You can turn on and off all the optional features that would normally
> be set by the host application using the test app's input form.
>
> Feature list:
>
>      Login component containing the following items
>      Username entry
>      Password entry
>      Login button
>      Forgot username button
>      Forgot password button
>      Register button
>      Remember my username on this computer checkbox (optional)
>      Log me in automatically when I return to this site checkbox (optional)
>
>   Register component containing the following items:
>      Username entry
>      Password entry
>      Confirm password entry
>      Email address
>      Recaptcha protection (optional)
>
>   Edit Account Detail component that allows
>      Change username
>      Change password
>      Change email address
>
>   Optional email confirmation of registration and account changes is provided.
>
>   Preferences that can be set by the host application or on the
> Seaside config page are:
>
>                'Confirm registrations via email.'.
>                'Minutes to wait after sending registration and password reset emails'.
>                'Protect registration form against spam with reCAPTCHA'.
>                'Outgoing mail server address or sending registration confirmation emails'.
>                'Confirm email address changes by sending email to the new address'.
>                'Confirm all account changes by sending email to the (possibly new) address'.
>                'Allow empty passwords'.
>                'Allow users to change their username'.
>                'Allow users to remember their username in a cookie'.
>                'Allow auto-login using username/password cookies'.
>                'Expiration period in days for username and password cookies'.
>                'Recaptcha public key - see http://www.google.com/recaptcha';
>                'Recaptcha private key - see http://www.google.com/recaptcha';
>
> The user information is persisted using the plug-in pattern. A
> ReferenceStream file persistence provider is provided as the default,
> but another persistence scheme could be plugged in in its place. There
> is an application properties dictionary included in the user object
> that is persisted and restored should the host application wish to
> make use of it.
>
> The confirmation email content is prepared by the hosting application
> through callbacks that provide the essential information needed, e.g.
> the URL the user must navigate to to confirm registration, the number
> of minutes within which they must do this, etc. Multi-part MIME email
> messages (HTML and plain text parts) are included as samples.
>
> My goal was to make this work out-of-the-box if all the defaults were
> acceptable, but allow the host application to override and substitute
> functionality where needed. Also I tried to minimize dependencies on
> outside packages other than Seaside 3.0.
>
> There are a number of things I was hoping to complete before letting
> anyone else see it, including refactoring, commenting, encrypting
> stored passwords, moving inline styles to a CSS file, and the like.
>
> There are also a number of additional features that I think should be
> added, such as security questions for use at public sites and security
> images and phrases like banking websites have, but I thought I would
> try integrating it into one of my own applications before doing any of
> that.
>
> If you are interested in the package in its current form, I can make
> an mcz file and send it to you -- probably by tomorrow. Caution is
> warranted though, I am still learning Seaside and the code needs a lot
> of cleanup -- that's what I'm working on now.
>
> Regards,
> TF
>
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
12