Overpowered answer: yes, in mod_perl; the
Apache request lifecycle has an authentication
phase, and mod_perl allows you to install a
'handler' which gets called at the beginning of the
authentication phase.
Such a handler could check to see whether the
directory corresponding to the requested URI has
a .wsl file and do the required work.
the drawback with this method is that mod_perl is wicked powerful and moderately complex.
| [reply] |
| [reply] |
I get the sense that what you're really trying to achieve is password protection for directories. You can easily set up password protection for directories using Apache, though it's not cookie based. See the
Apache FAQ for details.
| [reply] |
I already have password protection on directories, using Apache's
htaccess system. What I need is one that can send the user temporarily to another site
to enter their username/pass combo, which then sets a cookie. Then
I need the Apache server to verify that cookie exists on subsequent visits.
The expire time is set to '', causing them to have to re-visit the
password site each time they open the browser.
Is that making better sense?
I have the C code used as a starting point, but it's not working
and I am not a C person.
What does this little button do . .<Click>;
"USER HAS SIGNED OFF FOR THE DAY"
| [reply]
[d/l] |
That's a combination that may be hard to work with. The last project that I used authentication and Apache together initially used .htaccess files, but we scrapped that in favor of cookie checking code in all pages where users are supposed to be logged in. Here's a simple overview of how it worked:
Requests to index page were redirected to an SSL page that had a form for username/password entry. A successful username/password entry caused an entry with a generated session ID to be made in an Oracle database, and a cookie was sent back to the browser with the session ID. Once the username and password were authenticated, the user was redirected back to the "logged in" index page. All pages that required a user to be logged in had a bit of code included at the very top that checked the session ID and verified through the DB that the user was logged in. If the cookie was missing, or the user was not listed in the DB, the user was redirected back to the login page.
Not exactly the best of solutions as far as scalability and speed goes, but it might be a good starting point.
Guildenstern
Negaterd character class uber alles!
| [reply] |