Default user

[Matt Gerholdt]

Hello,

First of all, cog is great. I got it up and running and fetching news in a very short time. Woohoo!

I was wondering if cog currently supports a default or public user concept. For example, when a user hits a cog site for the first time, they would be presented with a default layout. If the user so desired, they could then request an account (via email/whatever) - which would allow individual customization of the layout. The thing I don't want is for a new surfer to hit a login screen first thing.

I goofed around a bit and tweaked cog.pl to read a default user out of the config file, and that seems to work ok. I was curious if anyone has a more elegant solution? The cog example pages already appears to work without a login, I just don't see how it is done  . . .

Thanks!

- Matt

[David Leadbeater]

The user on the demo is a serious hack.
It basically replaces the user subroutine with
$id=1 unless $id=$query->param('id');
and the id file contains the users demo and test, it's not suitable for use on
a site where users need to login but the idea is the same, basically set up a
default user if the id is not sent, the best way to do this is to add a user
called default, then DELETE them from the users/passwd file and put a line like
this in the users/id file:
default:1 (change the name if you want)
Then apply this tiny patch to cog.pl (against 0.07)

186,187c186,188
< # no user supplied - print login page
<       &login_page;
---
> # show default user
>       $id=1;
>       &user_id;

and hopefully it will work (I've not tested it, tell me what happens)

Then have a simple applet to print a login page set up on the default user:

print <<EOF;
<form action="$ENV{SCRIPT_NAME}" method="post">
<label>User</label><input type="text" name="user"><br>
<label>Password</label><input type="password" name="pwd"><br>
</form>
EOF

The final thing to do is to chmod the default users configuration files, so
people don't mess them up, you should see what people do to the user test on
the demo!
I'll hopefully add this properly to the next release with a toggle in the config file.

[Matt Gerholdt]

Yep, that works pretty well! The only problem I had was with cookies. Here is a scenario:
+ Hit cog.pl, default login ok, portal displayed
+ Use login applet to login as user
   - cog.pl sets a cookie with generated user id
   - cog.pl adds session id to users/id
+ Goof around
+ Hit the Logout link in the wms applet
   - cog.pl deletes session id from users/id
+ Arrive at the login page OK
+ Surf around elsewhere, come back to cog.pl
   Oops: now I get the login page?!

The problem appears to be that cookies persist longer than the session id's kept in users/id. For example, the session id's are deleted on logout, but the cookie sticks around (for 2 years? lol). So . . . when I hit cog.pl with a cookie, it extracts the id and checks it against users/id. But, the session id is no longer valid, so I get the good ol' login screen.

Whew! I tried a couple hacks, here's one of them:

96,102d95
<                  # Set cookied id to default (1) mjg, 3 Aug 2000
<                $cookie = $query->cookie(-name=>'id',
<                                           -value=>'1',
<                                           -expires=>'+2y',);
<                print $query->header(-Pragma=>'no-cache',
<                                       -cookie=>$cookie);
<                $header=1;
193,196c186,187
< # Default user patch from dgl, 3 Aug 2000
< # show default user
<        $id=1;
<        &user_id;
---
> # no user supplied - print login page
>       &login_page;

The first code snippet is invoked when a user logs out . . it effectively resets the cookied id to "1". A quick glance at the CGI.pm docs didn't immediately show how to delete a cookie, assuming that is legal.

The other hack I tried was this:

183c183,185
<                &login_page;
---
> # Default user hack, mjg 3 Aug 2000
>              $id=1;
>              &user_id;

This one is used when a session id is supplied (via cookie or post), and it is not found in the users/id file. A logical? extension to your tweak.

Both hacks seemed to work with my limited testing. I thought a rogue cookied id might cause problems (as leftover with the 2nd hack), but I did not find any evidence to support that theory.

Thanks for the quick response! If something I said doesn't make sense (and you care :), just let me know.

- Matt

[David Leadbeater]

Okay, I knew I had missed something out ;)
I don't know whether you thought of this, but why don't you just put the
$id=1;
&user_id;
snippet in login_page instead of the login code which is in a seperate applet, and then whenever for some reason or other it would print the login page it could just print the default user, maybe I should of suggested that orginally....
I'm not sure how to delete a cookie (can you?) but setting no value seems to work fine (and then $query->cookie('id') isn't true), like this:
my $cookie = $query->cookie(-name=>'id',-value=>'',-expires=>'+2y')
and then it would work fine on user based cog installs too.

We now hit the usual problem of the code being in CVS but not yet released as this has been in CVS for the past few days as the login code is much cleaner! (but doesn't work on FreeBSD as it uses crypt) but CVS is not ready for release as it needs the configuration of modules rewriting.

Hopefully that is what you need and if you have any more ideas i'm willing to accept them ;)