Seaside authentication/login/user account package
Locked
 
|
Hello all,
I have just published the TFLogin package at http://www.squeaksource.com/TFLogin. This package provides basic user authentication, registration, and account management for Seaside. Features include: . User login component with username and password text fields, forgot username, forgot password, register, and login buttons. . User registration component with optional reCaptcha spambot protection. . Edit account settings component allows user to change username, password, email address and application-specific properties. . Optional email confirmation for registration and account changes. Email content is provided by the host application. Examples are included. . Multi-part HTML/plain text email. . Configurable confirmation email timeouts and cookie retention periods. . Forgot username and forgot password support. . Options to allow empty passwords, remember username in cookie, and automatic login on return to the website. . Add additional user-related objects to the account edit form. . An application properties dictionary is provided that allows you to store and retrieve additional objects along with the user account information. . All settings are available in the Seaside configuration page. . Test/demo application included. . TFLogin Guide document included (see the Wiki tab.) Persistence is provided by a storage adaptor that can be replaced with the persistence mechanism of your choice. The default provided is a reasonably scalable file-based system using ReferenceStreams. Each user's information is saved in a separate versioned file. Tested with Seaside 3.0.3 and Pharo 1.1.1. Email does NOT work with prior versions of Seaside. See the Squeaksource project Wiki tab for the complete TFLogin Guide document. I have integrated this successfully with one of my own existing web apps and of course the test app included in the package works fine. This is *not* a lot of testing and this is definitely version 1.0 or less, so I expect bugs a-plenty will be found. I am still refactoring the code, but that should not change the functionality or the public API. All feedback is welcome. Regards, TF _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Oh, the test app is running at http://www.ensurete.com/LoginTestApp ;).
On Thu, Jan 6, 2011 at 2:31 PM, Tony Fleig <[hidden email]> wrote: > Hello all, > > I have just published the TFLogin package at > http://www.squeaksource.com/TFLogin. > > This package provides basic user authentication, registration, and > account management for Seaside. > > Features include: > > . User login component with username and password text fields, > forgot username, forgot password, register, and login buttons. > > . User registration component with optional reCaptcha spambot protection. > > . Edit account settings component allows user to change username, > password, email address and application-specific properties. > > . Optional email confirmation for registration and account > changes. Email content is provided by the host application. Examples > are included. > > . Multi-part HTML/plain text email. > > . Configurable confirmation email timeouts and cookie retention periods. > > . Forgot username and forgot password support. > > . Options to allow empty passwords, remember username in cookie, > and automatic login on return to the website. > > . Add additional user-related objects to the account edit form. > > . An application properties dictionary is provided that allows you > to store and retrieve additional objects along with the user account > information. > > . All settings are available in the Seaside configuration page. > > . Test/demo application included. > > . TFLogin Guide document included (see the Wiki tab.) > > Persistence is provided by a storage adaptor that can be replaced with > the persistence mechanism of your choice. The default provided is a > reasonably scalable file-based system using ReferenceStreams. Each > user's information is saved in a separate versioned file. > > Tested with Seaside 3.0.3 and Pharo 1.1.1. Email does NOT work with > prior versions of Seaside. > > See the Squeaksource project Wiki tab for the complete TFLogin Guide document. > > I have integrated this successfully with one of my own existing web > apps and of course the test app included in the package works fine. > This is *not* a lot of testing and this is definitely version 1.0 or > less, so I expect bugs a-plenty will be found. I am still refactoring > the code, but that should not change the functionality or the public > API. > > All feedback is welcome. > > Regards, > TF > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I updated TFLogin to add the capability for the host application to
reject proposed new user passwords and supply error text to be displayed to the user. This occurs during registration, account editing, and password reset. This will allow application-specific requirements such as minimum length, presence of upper- and lower-case letters, numbers and punctuation and the like to be enforced. It seems squeaksource is down at the moment. I'll try publishing the update tomorrow (Pacific Time). Regards, TF On Thu, Jan 6, 2011 at 2:33 PM, Tony Fleig <[hidden email]> wrote: > Oh, the test app is running at http://www.ensurete.com/LoginTestApp ;). > > On Thu, Jan 6, 2011 at 2:31 PM, Tony Fleig <[hidden email]> wrote: >> Hello all, >> >> I have just published the TFLogin package at >> http://www.squeaksource.com/TFLogin. >> >> This package provides basic user authentication, registration, and >> account management for Seaside. >> >> Features include: >> >> . User login component with username and password text fields, >> forgot username, forgot password, register, and login buttons. >> >> . User registration component with optional reCaptcha spambot protection. >> >> . Edit account settings component allows user to change username, >> password, email address and application-specific properties. >> >> . Optional email confirmation for registration and account >> changes. Email content is provided by the host application. Examples >> are included. >> >> . Multi-part HTML/plain text email. >> >> . Configurable confirmation email timeouts and cookie retention periods. >> >> . Forgot username and forgot password support. >> >> . Options to allow empty passwords, remember username in cookie, >> and automatic login on return to the website. >> >> . Add additional user-related objects to the account edit form. >> >> . An application properties dictionary is provided that allows you >> to store and retrieve additional objects along with the user account >> information. >> >> . All settings are available in the Seaside configuration page. >> >> . Test/demo application included. >> >> . TFLogin Guide document included (see the Wiki tab.) >> >> Persistence is provided by a storage adaptor that can be replaced with >> the persistence mechanism of your choice. The default provided is a >> reasonably scalable file-based system using ReferenceStreams. Each >> user's information is saved in a separate versioned file. >> >> Tested with Seaside 3.0.3 and Pharo 1.1.1. Email does NOT work with >> prior versions of Seaside. >> >> See the Squeaksource project Wiki tab for the complete TFLogin Guide document. >> >> I have integrated this successfully with one of my own existing web >> apps and of course the test app included in the package works fine. >> This is *not* a lot of testing and this is definitely version 1.0 or >> less, so I expect bugs a-plenty will be found. I am still refactoring >> the code, but that should not change the functionality or the public >> API. >> >> All feedback is welcome. >> >> Regards, >> TF >> > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
thank you!
On Fri, Jan 7, 2011 at 6:37 AM, Tony Fleig <[hidden email]> wrote: > I updated TFLogin to add the capability for the host application to > reject proposed new user passwords and supply error text to be > displayed to the user. This occurs during registration, account > editing, and password reset. > > This will allow application-specific requirements such as minimum > length, presence of upper- and lower-case letters, numbers and > punctuation and the like to be enforced. > > It seems squeaksource is down at the moment. I'll try publishing the > update tomorrow (Pacific Time). > > Regards, > TF > > On Thu, Jan 6, 2011 at 2:33 PM, Tony Fleig <[hidden email]> wrote: >> Oh, the test app is running at http://www.ensurete.com/LoginTestApp ;). >> >> On Thu, Jan 6, 2011 at 2:31 PM, Tony Fleig <[hidden email]> wrote: >>> Hello all, >>> >>> I have just published the TFLogin package at >>> http://www.squeaksource.com/TFLogin. >>> >>> This package provides basic user authentication, registration, and >>> account management for Seaside. >>> >>> Features include: >>> >>> . User login component with username and password text fields, >>> forgot username, forgot password, register, and login buttons. >>> >>> . User registration component with optional reCaptcha spambot protection. >>> >>> . Edit account settings component allows user to change username, >>> password, email address and application-specific properties. >>> >>> . Optional email confirmation for registration and account >>> changes. Email content is provided by the host application. Examples >>> are included. >>> >>> . Multi-part HTML/plain text email. >>> >>> . Configurable confirmation email timeouts and cookie retention periods. >>> >>> . Forgot username and forgot password support. >>> >>> . Options to allow empty passwords, remember username in cookie, >>> and automatic login on return to the website. >>> >>> . Add additional user-related objects to the account edit form. >>> >>> . An application properties dictionary is provided that allows you >>> to store and retrieve additional objects along with the user account >>> information. >>> >>> . All settings are available in the Seaside configuration page. >>> >>> . Test/demo application included. >>> >>> . TFLogin Guide document included (see the Wiki tab.) >>> >>> Persistence is provided by a storage adaptor that can be replaced with >>> the persistence mechanism of your choice. The default provided is a >>> reasonably scalable file-based system using ReferenceStreams. Each >>> user's information is saved in a separate versioned file. >>> >>> Tested with Seaside 3.0.3 and Pharo 1.1.1. Email does NOT work with >>> prior versions of Seaside. >>> >>> See the Squeaksource project Wiki tab for the complete TFLogin Guide document. >>> >>> I have integrated this successfully with one of my own existing web >>> apps and of course the test app included in the package works fine. >>> This is *not* a lot of testing and this is definitely version 1.0 or >>> less, so I expect bugs a-plenty will be found. I am still refactoring >>> the code, but that should not change the functionality or the public >>> API. >>> >>> All feedback is welcome. >>> >>> Regards, >>> TF >>> >> > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside authentication/login/user account package
|
|
In reply to this post by tfleig
Tony,
On 06 Jan 2011, at 23:31, Tony Fleig wrote: > I have just published the TFLogin package at > http://www.squeaksource.com/TFLogin. > > This package provides basic user authentication, registration, and > account management for Seaside. This is great work ! Thanks for publishing and sharing this. Sven _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
In reply to this post by tfleig
Tony,
nice work indeed. Two things Class variable names should be capitalized, so in TLApplicationPropertyItem with displayName and userModifiable. I saw that you just copied over my reCaptcha implementation from http://www.squeaksource.com/BowWave into your package only changing the Classnameprefix from BW to TL and leaving out one configuration class. I just wonder why it wasn't possible for you to just use the component as it is and you were forced to do a plain copy&paste? Alex 2011/1/6 Tony Fleig <[hidden email]> Hello all, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Alex,
Thank you for noticing those uncapitalized class variables. They are in fact unused so I have removed them. (I'm sure there are many more issues like this in the code.) Thank you also for producing the BowWave reCaptcha package that I used. I actually made more changes to the BowWave code than simply copying and renaming. At the time I downloaded it, sometime in November or early December 2010, I had to make some changes (small ones, I don't remember exactly what now) to allow it to function in Pharo 1.1/Seaside 3.0 and I changed it to use callbacks store: as well. I assumed since there had been no activity in the package for nearly a year and since it wouldn't work out-of-the-box that it was not being maintained any longer. (I see now it would have been better for me to have sent you an email about it.) I didn't want to distribute a package that depended on a another package that was not kept current, so I incorporated the BW components into TFLogin. I see now that the you have made the same changes that I did and clearly the package is still being maintained. I would certainly prefer to have you maintaining the reCaptcha stuff and I believe in code reuse generally so I will remove the TL reCaptcha classes in TFLogin and simply require the BowWave packages be present if the reCaptcha option is used in TFLogin. (And of course update the documentation to reflect the change and direct the user to the BowWave reCaptcha package.) This may take me a day or two. Thanks again for the BowWave reCaptcha package and for reviewing TFLogin. Regards, TF On Fri, Jan 7, 2011 at 3:14 AM, Alexander Lazarević <[hidden email]> wrote: > Tony, > > nice work indeed. Two things > > Class variable names should be capitalized, so in TLApplicationPropertyItem > with displayName and userModifiable. > > I saw that you just copied over my reCaptcha implementation from > http://www.squeaksource.com/BowWave into your package only changing the > Classnameprefix from BW to TL and leaving out one configuration class. > I just wonder why it wasn't possible for you to just use the component as it > is and you were forced to do a plain copy&paste? > > Alex > > 2011/1/6 Tony Fleig <[hidden email]> >> >> Hello all, >> >> I have just published the TFLogin package at >> http://www.squeaksource.com/TFLogin. >> >> This package provides basic user authentication, registration, and >> account management for Seaside. >> >> Features include: >> >> . User login component with username and password text fields, >> forgot username, forgot password, register, and login buttons. >> >> . User registration component with optional reCaptcha spambot >> protection. >> >> . Edit account settings component allows user to change username, >> password, email address and application-specific properties. >> >> . Optional email confirmation for registration and account >> changes. Email content is provided by the host application. Examples >> are included. >> >> . Multi-part HTML/plain text email. >> >> . Configurable confirmation email timeouts and cookie retention >> periods. >> >> . Forgot username and forgot password support. >> >> . Options to allow empty passwords, remember username in cookie, >> and automatic login on return to the website. >> >> . Add additional user-related objects to the account edit form. >> >> . An application properties dictionary is provided that allows you >> to store and retrieve additional objects along with the user account >> information. >> >> . All settings are available in the Seaside configuration page. >> >> . Test/demo application included. >> >> . TFLogin Guide document included (see the Wiki tab.) >> >> Persistence is provided by a storage adaptor that can be replaced with >> the persistence mechanism of your choice. The default provided is a >> reasonably scalable file-based system using ReferenceStreams. Each >> user's information is saved in a separate versioned file. >> >> Tested with Seaside 3.0.3 and Pharo 1.1.1. Email does NOT work with >> prior versions of Seaside. >> >> See the Squeaksource project Wiki tab for the complete TFLogin Guide >> document. >> >> I have integrated this successfully with one of my own existing web >> apps and of course the test app included in the package works fine. >> This is *not* a lot of testing and this is definitely version 1.0 or >> less, so I expect bugs a-plenty will be found. I am still refactoring >> the code, but that should not change the functionality or the public >> API. >> >> All feedback is welcome. >> >> Regards, >> TF >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I have published an updated TFLogin package to
http://www.squeaksource.com/TFLogin. The changes are: The BowWave reCaptcha package is now used in place of using copies of the BowWave classes. The ability to delete user accounts has been added. The host application may now make use of TFLogin's email confirmation mechanism for its own purposes. The documentation has been updated to reflect the above changes. Regards, TF On Fri, Jan 7, 2011 at 7:58 AM, Tony Fleig <[hidden email]> wrote: > Alex, > > Thank you for noticing those uncapitalized class variables. They are > in fact unused so I have removed them. (I'm sure there are many more > issues like this in the code.) > > Thank you also for producing the BowWave reCaptcha package that I used. > > I actually made more changes to the BowWave code than simply copying > and renaming. At the time I downloaded it, sometime in November or > early December 2010, I had to make some changes (small ones, I don't > remember exactly what now) to allow it to function in Pharo > 1.1/Seaside 3.0 and I changed it to use callbacks store: as well. I > assumed since there had been no activity in the package for nearly a > year and since it wouldn't work out-of-the-box that it was not being > maintained any longer. (I see now it would have been better for me to > have sent you an email about it.) > > I didn't want to distribute a package that depended on a another > package that was not kept current, so I incorporated the BW components > into TFLogin. > > I see now that the you have made the same changes that I did and > clearly the package is still being maintained. I would certainly > prefer to have you maintaining the reCaptcha stuff and I believe in > code reuse generally so I will remove the TL reCaptcha classes in > TFLogin and simply require the BowWave packages be present if the > reCaptcha option is used in TFLogin. (And of course update the > documentation to reflect the change and direct the user to the BowWave > reCaptcha package.) > > This may take me a day or two. > > Thanks again for the BowWave reCaptcha package and for reviewing TFLogin. > > Regards, > TF > > > > On Fri, Jan 7, 2011 at 3:14 AM, Alexander Lazarević <[hidden email]> wrote: >> Tony, >> >> nice work indeed. Two things >> >> Class variable names should be capitalized, so in TLApplicationPropertyItem >> with displayName and userModifiable. >> >> I saw that you just copied over my reCaptcha implementation from >> http://www.squeaksource.com/BowWave into your package only changing the >> Classnameprefix from BW to TL and leaving out one configuration class. >> I just wonder why it wasn't possible for you to just use the component as it >> is and you were forced to do a plain copy&paste? >> >> Alex >> >> 2011/1/6 Tony Fleig <[hidden email]> >>> >>> Hello all, >>> >>> I have just published the TFLogin package at >>> http://www.squeaksource.com/TFLogin. >>> >>> This package provides basic user authentication, registration, and >>> account management for Seaside. >>> >>> Features include: >>> >>> . User login component with username and password text fields, >>> forgot username, forgot password, register, and login buttons. >>> >>> . User registration component with optional reCaptcha spambot >>> protection. >>> >>> . Edit account settings component allows user to change username, >>> password, email address and application-specific properties. >>> >>> . Optional email confirmation for registration and account >>> changes. Email content is provided by the host application. Examples >>> are included. >>> >>> . Multi-part HTML/plain text email. >>> >>> . Configurable confirmation email timeouts and cookie retention >>> periods. >>> >>> . Forgot username and forgot password support. >>> >>> . Options to allow empty passwords, remember username in cookie, >>> and automatic login on return to the website. >>> >>> . Add additional user-related objects to the account edit form. >>> >>> . An application properties dictionary is provided that allows you >>> to store and retrieve additional objects along with the user account >>> information. >>> >>> . All settings are available in the Seaside configuration page. >>> >>> . Test/demo application included. >>> >>> . TFLogin Guide document included (see the Wiki tab.) >>> >>> Persistence is provided by a storage adaptor that can be replaced with >>> the persistence mechanism of your choice. The default provided is a >>> reasonably scalable file-based system using ReferenceStreams. Each >>> user's information is saved in a separate versioned file. >>> >>> Tested with Seaside 3.0.3 and Pharo 1.1.1. Email does NOT work with >>> prior versions of Seaside. >>> >>> See the Squeaksource project Wiki tab for the complete TFLogin Guide >>> document. >>> >>> I have integrated this successfully with one of my own existing web >>> apps and of course the test app included in the package works fine. >>> This is *not* a lot of testing and this is definitely version 1.0 or >>> less, so I expect bugs a-plenty will be found. I am still refactoring >>> the code, but that should not change the functionality or the public >>> API. >>> >>> All feedback is welcome. >>> >>> Regards, >>> TF >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
More bugfixes and a few new features published to
http://www.squeaksource.com/TFLogin. I'm done for the day. TF On Fri, Jan 7, 2011 at 12:53 PM, Tony Fleig <[hidden email]> wrote: > I have published an updated TFLogin package to > http://www.squeaksource.com/TFLogin. > > The changes are: > > The BowWave reCaptcha package is now used in place of using copies of > the BowWave classes. > > The ability to delete user accounts has been added. > > The host application may now make use of TFLogin's email confirmation > mechanism for its own purposes. > > The documentation has been updated to reflect the above changes. > > Regards, > TF > > > On Fri, Jan 7, 2011 at 7:58 AM, Tony Fleig <[hidden email]> wrote: >> Alex, >> >> Thank you for noticing those uncapitalized class variables. They are >> in fact unused so I have removed them. (I'm sure there are many more >> issues like this in the code.) >> >> Thank you also for producing the BowWave reCaptcha package that I used. >> >> I actually made more changes to the BowWave code than simply copying >> and renaming. At the time I downloaded it, sometime in November or >> early December 2010, I had to make some changes (small ones, I don't >> remember exactly what now) to allow it to function in Pharo >> 1.1/Seaside 3.0 and I changed it to use callbacks store: as well. I >> assumed since there had been no activity in the package for nearly a >> year and since it wouldn't work out-of-the-box that it was not being >> maintained any longer. (I see now it would have been better for me to >> have sent you an email about it.) >> >> I didn't want to distribute a package that depended on a another >> package that was not kept current, so I incorporated the BW components >> into TFLogin. >> >> I see now that the you have made the same changes that I did and >> clearly the package is still being maintained. I would certainly >> prefer to have you maintaining the reCaptcha stuff and I believe in >> code reuse generally so I will remove the TL reCaptcha classes in >> TFLogin and simply require the BowWave packages be present if the >> reCaptcha option is used in TFLogin. (And of course update the >> documentation to reflect the change and direct the user to the BowWave >> reCaptcha package.) >> >> This may take me a day or two. >> >> Thanks again for the BowWave reCaptcha package and for reviewing TFLogin. >> >> Regards, >> TF >> >> >> >> On Fri, Jan 7, 2011 at 3:14 AM, Alexander Lazarević <[hidden email]> wrote: >>> Tony, >>> >>> nice work indeed. Two things >>> >>> Class variable names should be capitalized, so in TLApplicationPropertyItem >>> with displayName and userModifiable. >>> >>> I saw that you just copied over my reCaptcha implementation from >>> http://www.squeaksource.com/BowWave into your package only changing the >>> Classnameprefix from BW to TL and leaving out one configuration class. >>> I just wonder why it wasn't possible for you to just use the component as it >>> is and you were forced to do a plain copy&paste? >>> >>> Alex >>> >>> 2011/1/6 Tony Fleig <[hidden email]> >>>> >>>> Hello all, >>>> >>>> I have just published the TFLogin package at >>>> http://www.squeaksource.com/TFLogin. >>>> >>>> This package provides basic user authentication, registration, and >>>> account management for Seaside. >>>> >>>> Features include: >>>> >>>> . User login component with username and password text fields, >>>> forgot username, forgot password, register, and login buttons. >>>> >>>> . User registration component with optional reCaptcha spambot >>>> protection. >>>> >>>> . Edit account settings component allows user to change username, >>>> password, email address and application-specific properties. >>>> >>>> . Optional email confirmation for registration and account >>>> changes. Email content is provided by the host application. Examples >>>> are included. >>>> >>>> . Multi-part HTML/plain text email. >>>> >>>> . Configurable confirmation email timeouts and cookie retention >>>> periods. >>>> >>>> . Forgot username and forgot password support. >>>> >>>> . Options to allow empty passwords, remember username in cookie, >>>> and automatic login on return to the website. >>>> >>>> . Add additional user-related objects to the account edit form. >>>> >>>> . An application properties dictionary is provided that allows you >>>> to store and retrieve additional objects along with the user account >>>> information. >>>> >>>> . All settings are available in the Seaside configuration page. >>>> >>>> . Test/demo application included. >>>> >>>> . TFLogin Guide document included (see the Wiki tab.) >>>> >>>> Persistence is provided by a storage adaptor that can be replaced with >>>> the persistence mechanism of your choice. The default provided is a >>>> reasonably scalable file-based system using ReferenceStreams. Each >>>> user's information is saved in a separate versioned file. >>>> >>>> Tested with Seaside 3.0.3 and Pharo 1.1.1. Email does NOT work with >>>> prior versions of Seaside. >>>> >>>> See the Squeaksource project Wiki tab for the complete TFLogin Guide >>>> document. >>>> >>>> I have integrated this successfully with one of my own existing web >>>> apps and of course the test app included in the package works fine. >>>> This is *not* a lot of testing and this is definitely version 1.0 or >>>> less, so I expect bugs a-plenty will be found. I am still refactoring >>>> the code, but that should not change the functionality or the public >>>> API. >>>> >>>> All feedback is welcome. >>>> >>>> Regards, >>>> TF >>>> _______________________________________________ >>>> seaside mailing list >>>> [hidden email] >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >>> >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >>> >> > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I have published yet another updated TFLogin package to
http://www.squeaksource.com/TFLogin. In addition to bugfixes, I added a feature allowing the host application to implement failed login policies such as disabling accounts after a number of failed login attempts. The test application now implements an example of this. Regards, TF On Fri, Jan 7, 2011 at 10:03 PM, Tony Fleig <[hidden email]> wrote: > More bugfixes and a few new features published to > http://www.squeaksource.com/TFLogin. I'm done for the day. > > TF > > > On Fri, Jan 7, 2011 at 12:53 PM, Tony Fleig <[hidden email]> wrote: >> I have published an updated TFLogin package to >> http://www.squeaksource.com/TFLogin. >> >> The changes are: >> >> The BowWave reCaptcha package is now used in place of using copies of >> the BowWave classes. >> >> The ability to delete user accounts has been added. >> >> The host application may now make use of TFLogin's email confirmation >> mechanism for its own purposes. >> >> The documentation has been updated to reflect the above changes. >> >> Regards, >> TF >> >> >> On Fri, Jan 7, 2011 at 7:58 AM, Tony Fleig <[hidden email]> wrote: >>> Alex, >>> >>> Thank you for noticing those uncapitalized class variables. They are >>> in fact unused so I have removed them. (I'm sure there are many more >>> issues like this in the code.) >>> >>> Thank you also for producing the BowWave reCaptcha package that I used. >>> >>> I actually made more changes to the BowWave code than simply copying >>> and renaming. At the time I downloaded it, sometime in November or >>> early December 2010, I had to make some changes (small ones, I don't >>> remember exactly what now) to allow it to function in Pharo >>> 1.1/Seaside 3.0 and I changed it to use callbacks store: as well. I >>> assumed since there had been no activity in the package for nearly a >>> year and since it wouldn't work out-of-the-box that it was not being >>> maintained any longer. (I see now it would have been better for me to >>> have sent you an email about it.) >>> >>> I didn't want to distribute a package that depended on a another >>> package that was not kept current, so I incorporated the BW components >>> into TFLogin. >>> >>> I see now that the you have made the same changes that I did and >>> clearly the package is still being maintained. I would certainly >>> prefer to have you maintaining the reCaptcha stuff and I believe in >>> code reuse generally so I will remove the TL reCaptcha classes in >>> TFLogin and simply require the BowWave packages be present if the >>> reCaptcha option is used in TFLogin. (And of course update the >>> documentation to reflect the change and direct the user to the BowWave >>> reCaptcha package.) >>> >>> This may take me a day or two. >>> >>> Thanks again for the BowWave reCaptcha package and for reviewing TFLogin. >>> >>> Regards, >>> TF >>> >>> >>> >>> On Fri, Jan 7, 2011 at 3:14 AM, Alexander Lazarević <[hidden email]> wrote: >>>> Tony, >>>> >>>> nice work indeed. Two things >>>> >>>> Class variable names should be capitalized, so in TLApplicationPropertyItem >>>> with displayName and userModifiable. >>>> >>>> I saw that you just copied over my reCaptcha implementation from >>>> http://www.squeaksource.com/BowWave into your package only changing the >>>> Classnameprefix from BW to TL and leaving out one configuration class. >>>> I just wonder why it wasn't possible for you to just use the component as it >>>> is and you were forced to do a plain copy&paste? >>>> >>>> Alex >>>> >>>> 2011/1/6 Tony Fleig <[hidden email]> >>>>> >>>>> Hello all, >>>>> >>>>> I have just published the TFLogin package at >>>>> http://www.squeaksource.com/TFLogin. >>>>> >>>>> This package provides basic user authentication, registration, and >>>>> account management for Seaside. >>>>> >>>>> Features include: >>>>> >>>>> . User login component with username and password text fields, >>>>> forgot username, forgot password, register, and login buttons. >>>>> >>>>> . User registration component with optional reCaptcha spambot >>>>> protection. >>>>> >>>>> . Edit account settings component allows user to change username, >>>>> password, email address and application-specific properties. >>>>> >>>>> . Optional email confirmation for registration and account >>>>> changes. Email content is provided by the host application. Examples >>>>> are included. >>>>> >>>>> . Multi-part HTML/plain text email. >>>>> >>>>> . Configurable confirmation email timeouts and cookie retention >>>>> periods. >>>>> >>>>> . Forgot username and forgot password support. >>>>> >>>>> . Options to allow empty passwords, remember username in cookie, >>>>> and automatic login on return to the website. >>>>> >>>>> . Add additional user-related objects to the account edit form. >>>>> >>>>> . An application properties dictionary is provided that allows you >>>>> to store and retrieve additional objects along with the user account >>>>> information. >>>>> >>>>> . All settings are available in the Seaside configuration page. >>>>> >>>>> . Test/demo application included. >>>>> >>>>> . TFLogin Guide document included (see the Wiki tab.) >>>>> >>>>> Persistence is provided by a storage adaptor that can be replaced with >>>>> the persistence mechanism of your choice. The default provided is a >>>>> reasonably scalable file-based system using ReferenceStreams. Each >>>>> user's information is saved in a separate versioned file. >>>>> >>>>> Tested with Seaside 3.0.3 and Pharo 1.1.1. Email does NOT work with >>>>> prior versions of Seaside. >>>>> >>>>> See the Squeaksource project Wiki tab for the complete TFLogin Guide >>>>> document. >>>>> >>>>> I have integrated this successfully with one of my own existing web >>>>> apps and of course the test app included in the package works fine. >>>>> This is *not* a lot of testing and this is definitely version 1.0 or >>>>> less, so I expect bugs a-plenty will be found. I am still refactoring >>>>> the code, but that should not change the functionality or the public >>>>> API. >>>>> >>>>> All feedback is welcome. >>>>> >>>>> Regards, >>>>> TF >>>>> _______________________________________________ >>>>> seaside mailing list >>>>> [hidden email] >>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>>> >>>> >>>> _______________________________________________ >>>> seaside mailing list >>>> [hidden email] >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>>> >>>> >>> >> > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside authentication/login/user account package
|
Hi Tony and list,
I'm using your TFLogin package and must say it's a very useful piece of work. Every app I coded needed most features yor package provides, and it's really convenient to have them ready made.
However, it is almost impossible to style its components because of inconsistencies in CSS classes and IDs, some components even have styles hardcoded in the rendering methods, which makes the styling process very tiresome for a designer. In some cases there's no other solution but to change the Smalltalk code or to use really ugly CSS/JS hacks. I really like your package, but I think a good refactoring focusing on breaking huge methods into smaller ones and structuring elements into divs and spans with their IDs and classes where needed would make it much easily pluggable.
An example: TLRegisterComponent >> renderContentOn: (...) self useRecaptchaInRegistrationForm ifTrue: [
html tableRow: [ html tableData colSpan: 2;
style: 'padding: 10px;'; "This should be the designer's choice, not the programmer's" id: 'registercaptcha';
with: captchaComponent]]. (...)Another example: TFForgotPasswordComponent >> renderContentOn:
html form class: 'forgotpasswordform';
with: [ html text: 'Enter your username below and we will send an email message to you that will allow you to set a new password.'; break. "It is impossible for a designer to add a vertical space between these two lines, as there are no divs or spans defined and the br element doesn't allow almost any styling. Even using a paragraph would work better"
html text: 'Username '. html textInput id: 'forgotpasswordusername';
callback: [ :v | self sendEmail: v ]. html break.
html button id: 'forgotpasswordokbtn'; callback: [
self answer ]; with: 'Ok']
I hope you consider these suggestions as constructive criticism, if you need help refactoring or deciding what the CSS structure should look like please do not hesitate contacting me, I'll be glad to help :) Cheers, Bernat Romagosa.
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Bernat,
Thanks very much for the criticism. I agree with you 100%. There is much that should be done to make the package easier for styling. I have to admit that I was leaving that work until I get my own projects that use TFLogin to the point where I needed to deal with the styling. There's nothing like a real-world example to expose problems -- as you have experienced. And I wanted to finish off the tests (which are about 80% complete) before I did any more refactoring so I would be able to tell whether I broke anything.
Unfortunately, I have been distracted by other issues and for the last few days have not been working with TFLogin. I can use all the help I can get with this. If you would like to modify the classes to follow your suggestions I can make you a developer for TFLogin on Squeaksource or you can email the code to me and I will make the replacements. I would love to have your help.
If that is not something you can do, I will make the changes in any case, but it might take longer than you would like (and of course they may not exactly meet your needs) as I will have less time for this than before for a while.
Thanks again for the suggestions. Regards, TF On Thu, Jan 27, 2011 at 2:29 AM, AxiNat <[hidden email]> wrote: Hi Tony and list, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside authentication/login/user account package
|
|
Hi Tony,
Sorry I took a bit long to answer. At the moment I'm a little bit too busy to focus on helping you refactor TFLogin, as I've just started developing a new application and I should put my efforts into having a working prototype as soon as possible, but if I got the time in the weeks to come I'll let you know.
For the moment I've just forked your package into my repository with 3 or 4 small changes I needed for the CSS to work, but those are just little quick hacks. Thanks for your dedication!
Bernat Romagosa.
2011/1/27 Tony Fleig <[hidden email]> Bernat, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside authentication/login/user account package
Administrator
|
Nice!
How about also adding support for the user to login using Facebook, Google, Yahoo, Twitter etc you see often on web applications these days? |
|
|
In reply to this post by Bernat Romagosa
No problem Bernat. I think I will be able to start on the refactoring of the rendering methods this week.
TF
On Mon, Jan 31, 2011 at 12:36 AM, AxiNat <[hidden email]> wrote: Hi Tony, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Geert Claes
I agree that many would probably fund it useful to have additional
login options such as via Facebook, Twitter, Google, etc. I'll add that to my list of requested features. There is a fair amount of work still needed just to refactor the existing code base that I need to complete before adding any new features though... Of course I built TFLogin primarily because I needed the functionality myself and I am generally against the use of consolidated logins (see http://forum.world.st/authentication-for-seaside-td3166481.html#a3167165.) Here are excerpts from the above-referenced email: Entrusting the security of all your on-line accounts to a single entity, be it Facebook, Twitter, or a national government provides a single point of failure for the security of the associated accounts. This is the same reason why using the same password for multiple accounts is ill-advised. I understand keeping track of many passwords is inconvenient and just automatically using one's Facebook login at another site is very convenient. Convenience is also the reason why people use the word "password" as their password. I, personally, would not use automatic Facebook or Twitter login for any but my insecure accounts -- and those are almost by definition, the accounts that are not very important to me. I have three friends whose on-line accounts were compromised and who lost significant amounts of money and suffered months of continued problems recovering from identity theft. These were not rich people. This does happen. I think there is still a place for per-site login and security, inconvenient as it may be. (I use http://www.husharoo.com to maintain my secret stuff.) Regards, TF On Mon, Jan 31, 2011 at 2:53 AM, Geert Claes <[hidden email]> wrote: > > Nice! > > How about also adding support for the user to login using Facebook, Google, > Yahoo, Twitter etc you see often on web applications these days? > -- > View this message in context: http://forum.world.st/Seaside-authentication-login-user-account-package-tp3178309p3248474.html > Sent from the Seaside General mailing list archive at Nabble.com. > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside authentication/login/user account package
|
Administrator
|
I agree with the security concerns for sensitive information and the "two groups" of accounts you talked about and indeed the Google/Yahoo/Facebook/Twitter login would be targeted at the insecure group :)
Anyhow, this is already a great start towards a re-usable authentication package! |
Re: Seaside authentication/login/user account package
|
|
In reply to this post by tfleig
Sure, though you can also maintain your own authentication service or,
in the meantime, at least introduce OpenID delegation to leave that option open to you in the future: http://www.intertwingly.net/blog/2007/01/03/OpenID-for-non-SuperUsers Julian On Mon, Jan 31, 2011 at 7:25 PM, Tony Fleig <[hidden email]> wrote: > I agree that many would probably fund it useful to have additional > login options such as via Facebook, Twitter, Google, etc. I'll add > that to my list of requested features. There is a fair amount of work > still needed just to refactor the existing code base that I need to > complete before adding any new features though... > > Of course I built TFLogin primarily because I needed the functionality > myself and I am generally against the use of consolidated logins (see > http://forum.world.st/authentication-for-seaside-td3166481.html#a3167165.) > > Here are excerpts from the above-referenced email: > > Entrusting the security of all your on-line accounts to a single > entity, be it Facebook, Twitter, or a national government provides a > single point of failure for the security of the associated accounts. > This is the same reason why using the same password for multiple > accounts is ill-advised. > > I understand keeping track of many passwords is inconvenient and just > automatically using one's Facebook login at another site is very > convenient. Convenience is also the reason why people use the word > "password" as their password. I, personally, would not use automatic > Facebook or Twitter login for any but my insecure accounts -- and > those are almost by definition, the accounts that are not very > important to me. > > I have three friends whose on-line accounts were compromised and who > lost significant amounts of money and suffered months of continued > problems recovering from identity theft. These were not rich people. > This does happen. > > I think there is still a place for per-site login and security, > inconvenient as it may be. > > (I use http://www.husharoo.com to maintain my secret stuff.) > > Regards, > TF > > > > > On Mon, Jan 31, 2011 at 2:53 AM, Geert Claes <[hidden email]> wrote: >> >> Nice! >> >> How about also adding support for the user to login using Facebook, Google, >> Yahoo, Twitter etc you see often on web applications these days? >> -- >> View this message in context: http://forum.world.st/Seaside-authentication-login-user-account-package-tp3178309p3248474.html >> Sent from the Seaside General mailing list archive at Nabble.com. >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside authentication/login/user account package
|
Administrator
|
In reply to this post by tfleig
|
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |