Is there an off-the-shelf Online Membership solution?

Cody Pendant has asked for the wisdom of the Perl Monks concerning the following question:

I have a membership, including a username and password, with about fifty places online, including here. They're all pretty much the same.

I was thinking, is there a module, or some kind of script library for setting up such a thing? I wouldn't mind doing this for an intranet application.

I mean they all pretty much have the same things.

Want to register? Already a member? Then log in here.
That's not your password! Forgotten it? Want it mailed to you?
We already have a member with that email address!
Check this box to set a cookie and we'll remember you next time.

...and so on.

The interface widgets are pretty accepted and formalised. Is everyone really still writing their own? You could write the same code and just plug in the database type, username and password, then wrap HTML around it.

TIA
--

($_='jjjuuusssttt annootthheer
     pppeeerrrlll haaaccckkeer')=~y/a-z//s;print;
[download]

Comment on Is there an off-the-shelf Online Membership solution? Download Code

Replies are listed 'Best First'.
Re: Is there an off-the-shelf Online Membership solution? by hiseldl (Priest) on Aug 06, 2002 at 13:37 UTC
Check out Everything. :) If you want other GPL software, there's Yet Another Web Portal System, and its derivatives WebApp and Poas. Out of these three WebApp seems to have the largest user base, and it has a semi-automatic install script. You can also take a look in CGI Resources Directories and Portals and CGI Expo Portal Scripts for other community portal scripts. Most of these are complete member site applications encompassing multiple scripts. If you just want some perl scripts that you can use to put together your own flavor of community check out Extropia.com for several open source web apps you can use for your site. -- hiseldl P.S. YAWPS, WebAPP, and POAS are all 100% Perl with no DB required.	[reply]
Re: Is there an off-the-shelf Online Membership solution? by hakkr (Chaplain) on Aug 06, 2002 at 13:35 UTC
Everyone writes their own, mainly because they vary depending on the type of authentication you choose. The main choice is Application or webserver level authentication with web server being more secure. Within web server authentication you can choose LDAP authentication or Basic authentication with .htaccess files. Within Application authentication you have to start thinking about tokens and session authentication. There are modules to support each type of authentication Net::LDAP, Apache::AuthenLdap, Apache::AuthenPasswwd for example. When you consider Microsoft Passport and the Liberty Alliance specification single sign on will be standardised into something everyone will have to use and maybe then we'll all get to use the same modules. It's a nice idea I just hope for my sake it is based around an ldap server	[reply]
Re: Is there an off-the-shelf Online Membership solution? by LTjake (Prior) on Aug 07, 2002 at 00:53 UTC
My own approach was to use CGI::Application. The advantage I found was that a) support for HTML::Template is built-in, thus allowing me to use any template design I want. b) I can create a super-class that can auto-magically take care of session and user management each time one of my scripts runs. Basically it looks like this: script.cgi: `use MySite::SubClass; my $webapp = MySite::SubClass->new(); $webapp->run();` [download] MySite::SubClass: `package MySite::SubClass; use MySite::SuperClass; sub setup { # setup runmodes and script specific stuff # ...templates perhaps? } # … # runmodes subs and whatnot :) # … 1;` [download] MySite::SuperClass: `package MySite::SuperClass; use base 'CGI::Application'; use CGI; # other modules here.. sub cgiapp_init { my $self = shift; # create database handler # do session management } sub teardown { my $self = shift; # dbh->disconnect } # … # other functions # … 1;` [download] You can then create MySite::SubClass2 (etc…) which all use MySite::SuperClass and thus have session management taken care of.	[reply] [d/l] [select]
Re: Is there an off-the-shelf Online Membership solution? by smalhotra (Scribe) on Aug 06, 2002 at 18:13 UTC
I started a project along the same lines last summer. Never got to far. I tried again this summer, but the inspiration just seems to be lacking. See it here. If anyone has any suggestions or encouragement, please send to smalhotra@redeyetg.com. $will->code for @food or $$;	[reply]
Re: Is there an off-the-shelf Online Membership solution? by Cody Pendant (Prior) on Aug 07, 2002 at 02:27 UTC
Thanks everyone for your help. For the record, I downloaded YaWPS, which was small, quick to configure, uses cookie-based session authentication, and is hugely packed with features. My only problem will be removing all the features I don't need. -- `($_='jjjuuusssttt annootthheer pppeeerrrlll haaaccckkeer')=~y/a-z//s;print;` [download]	[reply] [d/l]
Re: Is there an off-the-shelf Online Membership solution? by Ryszard (Priest) on Aug 07, 2002 at 07:35 UTC
I rolled my own Application Framework - why? because of the experience gained. It really isnt very difficult to get right. I've created a superclass that inherits from cgi::application that implicitly manages sessions and access control (in a secure manner, using "non determinate" tokens and a postgres backend. All a programmer has to do is `use base 'AppFrame'` and write their application in a cgi::app style, add it to the database (for access control et al), and wuh-lah the applicaton is visible. The authentication scheme is such that if i wanted to change to ldap, rather than an RDBMS, i just write another module with the same methods, and switch it over... nice and simple... ;-)	[reply] [d/l]
Re: Is there an off-the-shelf Online Membership solution? by Ryszard (Priest) on Aug 07, 2002 at 13:19 UTC
LTjake has asked me to elaborate (via the CB) on how I perform my access control and authentication. Not sure if a "design" should be posted here, however its related to the topic, so here goes: I've written objects to take care of authentication and access control. The two objects are called session.pm and (pooly named) login.pm Session.pm manages the session. When a user logs in, the supply their username and password. Session.pm goes and hashes the incoming password, and compares it to the password in the database (using the username). If the password matches (encrypt and compare) it then creates a "non determinate" token and issues it to the browser via a cookie, and also stores it in a session table alongside the primary (artificial) key of the user. Access control is a vanilla users -> group, and group -> application style. Access control can also be done at the method level in the same way (ie group -> method). This type of method level control must be explicitly programmed by the application programmer. The AppFrame is based on cgi::app so for each new application you do a `use base 'AppFrame'` (which in turn uses CGI::Application). Each time the application is invoked a method in AppFrame goes and checks to see if the user (based on the session id retrieved from the cookie) has access to the page (url) they want to access. ie its all implicit. the application programmer doesnt have to worry about either verifying access, or verifying a session. The current AppFrame GUI design has a level of menus down the lefthand side for each applicaton. If you dont have access to an application, its icon will not be shown. (This is handled by the poorly named login.pm module.) The tables used at the back end are: users - contains the users groups - contains the groups usr-grp - maps a user to a group applications - contains all the applications app-grp - which groups have access to which application. session - lists each session, user id, create time etc So its easy to grab the sess_id from the cookie, look up the user's group, and see if the group has access to an application. As a short term (non scalable solution) i've make the login method purge any expired sessions from the session table. This was done because the application (as a whole) will only ever have a few users (<100) so performance was not an issue I keep away from globals, and rather use "Encapsulated Class data" (as per conway's style.). This way you can do something like `$self->{_sess_id}`. This variable will be populated using the constructor from the cookie. You can then do something like `if $self->_fetch_sess_id() eq $self->{_sess_id}` to determine if a session is valid or not. Needless to say, because of cgi::apps support of HTML::Template the whole framework is template driven, and can easily have "themes" built into it. The whole deal is not very sophisticated, and certainly not an "Everything" engine, but it works, and is very effective in our context. Anyways, hope this makes things a little clearer.	[reply] [d/l] [select]
Re: Is there an off-the-shelf Online Membership solution? by orkysoft (Friar) on Aug 07, 2002 at 17:47 UTC
I've also made something like what other people here have made. A 'plug-in' solution to authenticate logged in users (and of course log in users etc.). It's really easy to write an application to use it, too. It doesn't have many features yet, because it's still very simple. But it uses cookies like merlyn recommends in his WebTechniques column. Lur: "But if this cape shrinks, consider your species extinct!"	[reply]

Back to Seekers of Perl Wisdom