Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Streamlining login to Web site

Reply
Thread Tools

Streamlining login to Web site

 
 
mailbox@cpacker.org
Guest
Posts: n/a
 
      07-09-2007
For an existing suite of CGI scripts, I have
a task to improve the site's login access,
and I would like to know if CGI::Auth is
what I need.

Right now, the user must log in to gain
access to the main menu page, which is a
static HTML page. If he then clicks on
certain menu items that require
more privileged access, he will be
presented with the login dialogue again.
I understand how this has been set up by
configuring httpd.conf.

What I would like to do is determine the
user's access level at his initial login
and generate the appropriate main menu
page, thereby removing the need for any
further logins. If CGI::Auth is what I
need for this, are there any good tutorials
on using it, maybe with a really well
spelled-out example?

--
Charles Packer
http://cpacker.org/whatnews
mailboxATcpacker.org

 
Reply With Quote
 
 
 
 
J. Gleixner
Guest
Posts: n/a
 
      07-09-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> For an existing suite of CGI scripts, I have
> a task to improve the site's login access,
> and I would like to know if CGI::Auth is
> what I need.
>
> Right now, the user must log in to gain


How is that login handled? HTTP authentication?
A form and CGI?

> access to the main menu page, which is a
> static HTML page. If he then clicks on
> certain menu items that require
> more privileged access, he will be
> presented with the login dialogue again.
> I understand how this has been set up by
> configuring httpd.conf.


If it's configured properly and if the user is authorized
to get documents from that directory/URL, then that
shouldn't happen.

If you want to stick with HTTP authentication,
then read a few documents about it and using groups.

>
> What I would like to do is determine the
> user's access level at his initial login
> and generate the appropriate main menu
> page, thereby removing the need for any
> further logins. If CGI::Auth is what I
> need for this, are there any good tutorials
> on using it, maybe with a really well
> spelled-out example?


Sounds like you're after a more dynamic page approach where
the static HTML would be generated, some how, based on
something about the user name. It could be
via a CGI, HTML::Mason (www.masonhq.com), or possibly
PHP (php.net) might be a solution. You may use
CGI:Auth to help manage authentication, or do it
yourself, either way you'll have to learn about
generating HTML dynamically and come up with how
to apply the logic.
 
Reply With Quote
 
 
 
 
Peter J. Holzer
Guest
Posts: n/a
 
      07-09-2007
On 2007-07-09 20:16, (E-Mail Removed) <(E-Mail Removed)> wrote:
> For an existing suite of CGI scripts, I have
> a task to improve the site's login access,
> and I would like to know if CGI::Auth is
> what I need.
>
> Right now, the user must log in to gain
> access to the main menu page, which is a
> static HTML page. If he then clicks on
> certain menu items that require
> more privileged access, he will be
> presented with the login dialogue again.
> I understand how this has been set up by
> configuring httpd.conf.


First, you should make yourself clear the difference between
authentitication and authorization:

* authentication is establishing who a user is.

* authorization is establishing what a user is allowed to do.

HTTP Basic authentication muddies the distinction both in the headers
(The server sends a WWW-Authenticate header and the client responds with
an Authorization header) and in the behaviour of the common browsers.

But it is still very useful to keep them apart.

In HTTP basic authentication, a user is identified by four pieces of
information:

1) The server (identified by protocol, server and port).

2) The Realm (as sent in the WWW-Authenticate header and specified in
the AuthName directive in Apache)

3) The user name (as sent by the client in the Authorization header).

These three pieces uniquely identify a user. If one of them is
different, it is a different user. For the user to prove that he really
this user (to "authenticate" itself), the fourth piece is needed:

4) The password (sent by the client in the Authorization header).

Once you have authenticated the user, you need to decide what he can do.
For example Alice may access directory directory A, but not Directory B,
while Bob may access both directories.

In the Apache config, this is done with allow/deny and require
directives.

Note that HTTP has no way to confer that a user has successfully
authenticated, but is not authorized to access some resource. Both a
failed authentication and an attempt to access a resource without proper
authorization result in a 401 code. So when the browser receives a 401
code, it doesn't know whether the user supplied a wrong username or
password or isn't allowed to access that resource. So it pops up a
dialog box asking for username and password in either case.



> What I would like to do is determine the
> user's access level at his initial login
> and generate the appropriate main menu
> page,


So you want to create a page containing only links which the user is
authorized to visit? Once a user has been authenticated, you can easily
do that if you know where the user has access (that sounds trivial, but
may not be - you may need to parse server config files and .htaccess
files to find out).

> thereby removing the need for any further logins.
> If CGI::Auth is what I need for this,


No. CGI::Auth is concerned with Authentication, not Authorization.

At first glance, CGI::Auth may help you in two aspects:

1) It doesn't use Basic Authentication, so you can distinguish between
lack of authentication and authorization - you can tell a user "you
aren't allowed to go there" without his browser losing the login
information.

2) Since you are doing authentication yourselves, you also need to edo
authorization - so if you want dynamic menus, you don't need to
parser your server config files to find out where the user is allowed
access.

But at second glance it is obvious that you don't need CGI::Auth for
this. You get the same effect if you use Apache only for authentication,
and do the authorization in your scripts.

hp


--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | (E-Mail Removed) |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
 
Reply With Quote
 
mailbox@cpacker.org
Guest
Posts: n/a
 
      07-10-2007
On Jul 9, 6:16 pm, "Peter J. Holzer" <(E-Mail Removed)> wrote:
> But at second glance it is obvious that you don't need CGI::Auth for
> this. You get the same effect if you use Apache only for authentication,
> and do the authorization in your scripts.


Ah, but I haven't figured out how my script can learn who the user is
after it's invoked following Basic authentication! If that information
is in the tutorials, I've missed it, somehow. That's why I went poking
around in the Auth documentation. Is the user name a variable in %ENV,
or where? Once I know the user, I can parse .htgroup, I guess, to
determine his access level and generate the appropriate menu.

--
Charles Packer
http://cpacker.org/whatnews
mailboxATcpacker.org

 
Reply With Quote
 
Tim Southerwood
Guest
Posts: n/a
 
      07-10-2007
(E-Mail Removed) wrote:

> On Jul 9, 6:16 pm, "Peter J. Holzer" <(E-Mail Removed)> wrote:
>> But at second glance it is obvious that you don't need CGI::Auth for
>> this. You get the same effect if you use Apache only for authentication,
>> and do the authorization in your scripts.

>
> Ah, but I haven't figured out how my script can learn who the user is
> after it's invoked following Basic authentication! If that information
> is in the tutorials, I've missed it, somehow. That's why I went poking
> around in the Auth documentation. Is the user name a variable in %ENV,
> or where? Once I know the user, I can parse .htgroup, I guess, to
> determine his access level and generate the appropriate menu.


Hi

Yes, the username is in %ENV - REMOTE_USER I think, but if you dump the
whole of %ENV it will be obvious on sight.

That var is guaranteed correct by apache/mod_cgi, so if it is set, then that
is the username that apache authorised.

HTH

Tim
 
Reply With Quote
 
mailbox@cpacker.org
Guest
Posts: n/a
 
      07-10-2007
On Jul 10, 10:40 am, Tim Southerwood <(E-Mail Removed)> wrote:

> Yes, the username is in %ENV - REMOTE_USER I think, but if you dump the
> whole of %ENV it will be obvious on sight.
>
> That var is guaranteed correct by apache/mod_cgi, so if it is set, then that
> is the username that apache authorised.


Yup, I just found "remote_user()" call documented in
the CGI module. You get the user name returned if the
script was protected, i.e. required login to be invoked, null
otherwise.
Thanks.

--
Charles Packer
http://cpacker.org/whatnews
mailboxATcpacker.org


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
List of free web site design, web site backgrounds, web site layoutsresources cyber HTML 0 12-21-2007 03:47 PM
List of free web site design, web site backgrounds, web site layoutsweb sites cyber HTML 1 12-19-2007 09:07 AM
Video streamlining control? msch-prv@bluewin.ch ASP .Net 1 08-03-2007 04:01 PM
streamlining clean up process someone Computer Support 1 01-01-2005 11:14 PM
Streamlining using services.msc Cloud Burst Computer Support 1 09-14-2004 05:15 PM



Advertisments