Embedding the authenticate dialog box in a page
Jamie Unwin
I am wondering is it possible to embed the authenticaton dialog box into a
web page, not literaly :-). But is it possible to write a script to get the
username and password and then :-
a) Get the server to compare the username and password with the ones held
in the auth.db file
b) Keep the state while the user is logged in
I know you can send a url in the form username:pass...@www.site.com but
this leaves the password exposed.
An added problem is that we have to use the existing server authentication
database, we cannot build our own user/password datebase.
The site is running on a Netscape Enterprise Server
Thanks in advance for any help
__________________________________________________
- Jamie Unwin Webmedia Ltd, 2 Kendall Place
- Web Developer London, W1H 3AH
__________________________________________________
- [e] ja...@webmedia.com [t] (0171) 224 7244
- [w] http://www.webmedia.com [f] (0171) 224 7049
__________________________________________________
Stunt Pope
In article <jamieu-ya02408000...@news-reader.bt.net>,
jam...@webmedia.com says...
>
>
>I am wondering is it possible to embed the authenticaton dialog box into a
>web page, not literaly :-). But is it possible to write a script to get the
>username and password and then :-
>
>a) Get the server to compare the username and password with the ones held
>in the auth.db file
>b) Keep the state while the user is logged in
>
if the user logs into a protected area of the site, the $REMOTE_USER
environment variable will be set to their login id. It will be avail.
to anything else they access that's behind the passwd protected area,
if you want this info avail. to a script, the script has to be behind
the passwd block too...(i.e. a script alias to: /inside-bin/)
is this what you mean?
(you could also set a cookie after they authenticate and use that to
track state)
--
Mark Jeftovic (aka: Mark Jeff or Vic, Stunt Pope)
SysAdmin, Private World Communications
mar...@shmOOze.net - http://www.shmOOze.net/~markjr
irc: L-bOMb motto: Pigritia, Impatientia et Adrogantia
Jamie Unwin
In article <jamieu-ya02408000...@news-reader.bt.net>,
ja...@webmedia.com wrote:
Since my last post I have be experimenting and looked at several possibilities :
(a) Telnet in and send a HTTP header as follows :-
GET /index.html HTTP/1.0
Authorization: BASIC hjfgjfhjghfjh= (this is user:password encoded in base64)
This should let me retrive a protected HTML page (but I can't get it to work !)
It still returns an unautorised header ? I could be me encoding the base54
bit wrong ?
(b) Even if I managed to send this header and it works I will still need to
keep the state in the browser, so that I don't need to send the
Authorization: header with every request (this would mean building some
kind of proxy server, or pipe for all request to pass through, between the
browser and the server (a complete overkill ?).
Is it therefore possible to send a cookie/command/header to the browser (we
can narrow browser down to Netscape and IE) which will set the
authentication details (in the same way as filling in a box)
Netscape seem to be doing this at this URL, take a look :-), or are they
using a database and ignoring the protection/authentication facilities of
their server ?
http://developer.netscape.com/bin/login?Tag=/&URI=/members/doc/community/doc
/faqs/client_tech.html
> I am wondering is it possible to embed the authenticaton dialog box into a
> web page, not literaly :-). But is it possible to write a script to get the
> username and password and then :-
>
> a) Get the server to compare the username and password with the ones held
> in the auth.db file
> b) Keep the state while the user is logged in
>
Kevin P. Neal
jam...@webmedia.com (Jamie Unwin) wrote:
>In article <jamieu-ya02408000...@news-reader.bt.net>,
>ja...@webmedia.com wrote:
>Since my last post I have be experimenting and looked at several possibilities :
>(b) Even if I managed to send this header and it works I will still need to
>keep the state in the browser, so that I don't need to send the
>Authorization: header with every request (this would mean building some
>kind of proxy server, or pipe for all request to pass through, between the
>browser and the server (a complete overkill ?).
HTTP is a stateless protocol. Attempting to build state on top of a
stateless protocol is a bad idea.
Besides, what's to stop an attacker from bypassing your "login" page
and accessing your site without a password?
Nope, use Basic authentication as it was meant to be used (protect a
whole swath of pages).
Cookies are also a bad idea, because they can be forged.
--
XCOMM Kevin P. Neal, Junior, Comp. Sci. - House of Retrocomputing
XCOMM mailto:kpn...@pobox.com - http://www.pobox.com/~kpn/
XCOMM kpn...@eos.ncsu.edu " *** StarDOS makes great coffee! ***"
XCOMM From a mid-80's advertisement in "Compute's GAZETTE", a C64/C128 mag
Nick Kew
>
> Cookies are also a bad idea, because they can be forged.
>
any more secure than a crypt()-encoded cookie?
I've used cookies with two systems, in order to provide readonly access
to a system for non-authenticated users. The alternative would have
been to maintain parallel systems (protected/open) accessing the same
document base.
--
Nick Kew
Jonathan Petruk
>Cookies are also a bad idea, because they can be forged.
scheme, where the cookie has some data that is encrypted. How could you
possibly forge a cookie like that? You would have to know what data is
in the key before it is encrypted, which would not be an easy task.
What we use is this:
- bits of the hostname
- a few characters of a "key" that is randomly generated and changes daily
We take this data, and encrypt it using crypt. On the next request, we
generate the same string, and use crypt to see if they match. If they do,
then Auth was successful, otherwise we fail and do a standard Basic Auth
before issuing a new cookie.
Because it changes daily, you would have to work pretty darn quickly to
decrypt the key before the end of the day. Not likely.
Jon Petruk
pet...@nortel.ca