Re: [cobalt-users] Merging AHTTPD and HTTPD User Passwords

["Brian Curtis" <admin@xxxxxxxxxxx>]

----- Original Message -----
From: "Erik OBrien" <eobrien@xxxxxxxxx>


> Not really sure how to describe this,
>
> I'm really hacking up my admin interface and would like to pull
> pages/applications from the /home/sites/sitex directory of my sites into
> the admin interface. I need to keep these password protected. .htaccess
> works fine, but after the user logs on the ahttpd server and a password
> protected page from the httpd server is loaded, it prompts for a
> password again. Annoying!
>
> Anyone know how to carry that over from both servers in one session?


If I have this correct, your attempting to pull protected pages from both
admin and public http servers in one session, and your running into the
problem of being prompted for the same username pw twice (once from each
server)?

How are you being prompted for a pw from the admin server, form or
.htaccess?

If it's .htaccess, make sure the realms match on both servers.  Once a user
is authenticated via .htaccess, the env var REMOTE_USER becomes available.
You could use this as an auth check w/o PW on the public server, though
that's a bit lacking in security.  I'm not all that familiar with the
internals of .htaccess, so I'm not sure if it also recognizes the domain &
server port it's called from.  If it does, then you might need to look for
another way of protecting the pages.

If your submitting a username/pw via a form on the admin server, then you'll
need to implement a similar auth scheme on the public server.  Maybe set a
cookie after successful login on the admin server, then have a small php (or
your choice of languages) script on the public server read that cookie and
re-auth invisibly against a db.  If the auth combo doesn't match, then you
can have it re-request the auth info, otherwise proceed w/o the user knowing
anything happened.  Of course this might involve some extra work, including
a duplicate user/pw database if you can't access the original auth db via
the public http server.

Just my thoughts based upon the information you supplied.  Hope it helps to
some degree.  Keep in mind that the implementation of any methods above will
most likely require much more work than the few steps I threw out there.

--
Brian Curtis