Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

password protected directory

 [1/3] from: jackseay:earthlink at: 16-Sep-2000 1:18


Is there a Rebol script to password protect a directory and/or file(s) on a server? Would the same script work on different servers? Would other files be needed? Would the password and user names file be plain text? What would need to be done to configure it? What HTML would include or call it? I found a program at rebol.org that looks like it might do the job, but if it does, what needs to be done to use it? http://rebol.org/general/auth.html *#*#*#*#*#*# To design the new structures of writing for screens is a profound issue of literary structure.  It is important to provide the best literary structure that we can, for hypertext, as the literature of tomorrow, determines in part the new structure of civilization. Civilization is in large part about, and around, what is written.  This is what we call literature. Literature is an endless river, connected, like water, in all directions.  Document connections go forward and backward in time, and sideways between documents.  Scholarship and fiction, political speeches and criticism, advertising, journalism and technical reports-- all affect each other and evolve in a constant flow of ideas and writings. ... Ted Nelson... Jack Seay [jackseay--usa--net] http://home.earthlink.net/~jackseay/jack

 [2/3] from: joel::neely::fedex::com at: 16-Sep-2000 10:10


Short answer: Use the standard authentication tools in your web server, unless there's some overriding concern they don't address (or you just want to play around with hairy crypto code for the fun of it). Long-winded answer below. ;-) -jn- [jackseay--earthlink--net] wrote:
> Is there a Rebol script to password protect a directory and/or > file(s) on a server? >
Why reinvent the wheel? User authentication is built into Apache (free) and Netscape's web server ($). Once you tell the server that a specific resource requires authentication (and set up the group/user/password info) the server automatically requires entry of userID and password for any access to that resource. Having said that, if you're REALLY paranoid about packet sniffing, you should be aware that the basic authentication scheme sends uID/pw responses in base64, so it's trivial for someone who can log your net traffic to crack.
> Would the same script work on different servers? > Would other files be needed? > Would the password and user names file be plain text? > What would need to be done to configure it? > What HTML would include or call it? >
If you DO decide you need to roll your own, the answer to all of the above would be, "It depends on how you want it to work and how it's written." In general, however, you'll own the entire server-side problem of how to maintain ACLs (and how to keep them secure from server-side attacks). If you want some other form of checking than the standard server tools, you can either write your own custom client or use CGI. If you write your own client, you own the entire problem of managing the client-side user interface, client/server protocols and interaction, and server-side processing. A non-trivial bit of work, to say the least. If you want to use a standard browser, then writing CGI scripts that require initial identification before serving back HTML content might be feasible (as in the following paragraph). A quick glance at the script you cited (VERY quick) leaves me with the impression that it's intended for a generic client/server usage scenario, not for HTTP specifically. That script appears to assume that the uID/pw data are available when auth-server is called, so you'd have to write your own wrapper around it to get that information ready and invoke auth-server at the right time, to get a yes/no answer to whether the user is authenticated. You'd also have to get the auth-client code to run (on client or server h/W) with data obtained from the user. In short, it looks like an interesting component part, but not a complete out-of-the-box solution. Off the top of my head, it appears that the quickest way to adapt it for web use would be to have an HTML form filled out by the user with uID/pw and run the authentication via CGI. If you don't include some tricks in your web page (such as encrypting the user entries with a JavaScript routine in the page itself) then you're back to the same sniffing vulnerability as the built-in scheme. In this case, why not just use the basic authentication? If you DO encrypt the data with JavaScript prior to sending it, you'll be broadcasting the JS encryption routine along with the page. If your threat model includes attackers who'd look at the code and try to figure out the inverse of your JS encryption routine, you'd need a good one-way (very hard to invert) function, and those are VERY non- trivial to design. Good luck; hope this helps! -jn-

 [3/3] from: greywolf:greyfade at: 16-Sep-2000 20:39


----- Original Message ----- From: <[jackseay--earthlink--net]> To: <[list--rebol--com]> Sent: Friday, September 15, 2000 11:18 PM Subject: [REBOL] password protected directory
> Is there a Rebol script to password protect a directory and/or > file(s) on a server?
<<quoted lines omitted: 6>>
> but if it does, what needs to be done to use it? > http://rebol.org/general/auth.html
if you're asking what i think, then you're asking about using .htaccess configuration files. there are several tutorials out there... somewhere. :P using .htaccess makes the server send a username/password request to the browser, where the user gets the familiar user/pass dialog. if the right password is not entered, the user gets an authorization denied message. this method locks all files in the directory and all its subdirectories. what you referred to last looks like an authentication script that redirects a usr to a specific page after providing the appropriate password(s).

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted