Re: authentication via login form
"Jeffrey" == Jeffrey W Baker [EMAIL PROTECTED] writes: Jeffrey Cookies are an acceptable way to make the browser remember Jeffrey something about your site. Speak for yourself. I'd change that to "... one possible way ..." instead of "acceptable way", and add "... for a single session". Cookies are evil when used for long-term identification. There is no one-to-one correspondance between a user and a browser, and yet cookies presume so. In a given week, I might use four or five browsers, and a few of those will be in public places, like libraries or client's sites. Be careful when you use cookies. Make sure it's your LAST choice. Mangled URLs and hidden fields are other straightforward alternatives. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: authentication via login form
The point that should be taken is that if one must use a cookie for auth, expire it early and often. What would _really_ be nice is if there were a javascript or ecmascribble or whatever it's called object that can _set_ or _unset_ the auth request headers so one _could_ do a form driven authentication that used HTTP standards (basic and digest authentication). Well, it'd be nice if browsers did a lot of things, like sent a useful header: Accept-code: ecmascribble/1.4, JVM/1.2, client-side-perl/6.0 ...the percentage of sites that actually use content negotiation is probably 5% yet the browsers send all this chatter about what they accept for content and nothing about programmatic capabilities. Fooey. But I digress. Go ahead, use cookies and mangle them into auth headers but make sure they aren't persistent cookies. And don't use this level of security for banking or commerce; those get mangled URL paths. In a self contained intranet world, using client certificates and mod_ssl sounds like a good proposition. -Ian Meanwhile, back at the ranch... Jeffrey Cookies are an acceptable way to make the browser remember Jeffrey something about your site. Be careful when you use cookies. Make sure it's your LAST choice. Mangled URLs and hidden fields are other straightforward alternatives. -- Salon Internet http://www.salon.com/ HTTP mechanic, Perl diver, Mebwaster, Some of the above Ian Kallen [EMAIL PROTECTED] / AIM: iankallen / Fax: (415) 354-3326
Re: authentication via login form
On Sun, 10 Oct 1999, Spidaman The Defenestrator wrote: [...snip...] But I digress. Go ahead, use cookies and mangle them into auth headers but make sure they aren't persistent cookies. And don't use this level of security for banking or commerce; those get mangled URL paths. In a self contained intranet world, using client certificates and mod_ssl sounds like a good proposition. [1] Client Certs Under certain circumstances, SSL and client certs for authentication for an Intranet is not necessarily that great. [A] Users do roam (a pain to support cert loading) [B] In a global organization, proxy infrastructure plays a part... SSL is impossible to proxy, and when it is, you can't proxy client certs. [C] SSL adds unnecessary overhead to the web server especially a heavily used Intranet one potentially. Client Certs are not necessarily more secure that username/passwords and/or securID over a normal SSL connection. It depends on the environment that the client cert is kept under control. [2] Mangled URL Paths Isn't it possible to browse the history on the harddrive... so is this really more secure than non-persistent cookies?
Embperl/Win32 offline problem
Hi, Embperl (1.2b6) in Randy Kobes' Win32 distribution doesn't work offline with following error: Can't load 'C:\PERL\site\5.00503\lib/MSWin32-x86/auto/HTML/Embperl/Embperl.dll' for module HTML::Embperl: load_file:Nelze nalzt jeden z knihovnch soubor potebnch pro sputn tto aplikace at C:\PERL\5.00503\lib/MSWin32-x86/DynaLoader.pm line 169. at C:\Projekty\ucetnispol\novy\convert.pl line 1 BEGIN failed--compilation aborted at C:\Projekty\ucetnispol\novy\convert.pl line 1. Process completed with exit code 2 convert.pl = use HTML::Embperl; use strict; use vars qw/@pages @languages/; = The missing Embperl.dll is of course there and under Apache/mod_perl Embperl works just fine. Thanks for your help. - Robert
RE: Embperl and Apache::Session (was: Installation problem whith Embperl)
I tried to install HTML::Embperl with Apache/mod_perl on a Sparc/Solaris server, but 'make test' failed with an error on the module Apache/Session/Win32.pm. Did someone already encounter/solve this kind of problem ? 1) My config is: OS = Solaris apache V1.3.9 mod_perl V1.21 Apache::Session V1.03 Perl V5.00503 Embperl V1.2b8 Apache::Session 1.03 is errornous! Use either Apache::Session 1.02 or upgrade to Embperl 1.2b10 and use Apache::Session 1.04. Both Apache::Session version are avialable form ftp://ftp.dev.ecos.de/pub/perl/embperl/ I hope Jeffery will put Apache::Session 1.04 soon on CPAN so these confusion will have an end. Gerald --- Gerald Richter ecos electronic communication services gmbh Internet - Infodatenbanken - Apache - Perl - mod_perl - Embperl E-Mail: [EMAIL PROTECTED] Tel:+49-6133/925151 WWW:http://www.ecos.de Fax:+49-6133/925152 ---
RE: sybase / mod_perl / linux question? [OFFTOPIC]
Interesting. I tested an identical setup of Apache/modperl/Embperl/Oracle on NT and Linux, and I experienced a huge slowdown on NT. When I looked into it, I found that the more database-intensive the page, the slower the relative performance of the NT platform. I took that to mean that it was actually Oracle on NT that was the root of the problem, but wasn't sure. I guess now I know. All mod_perl requests on NT are serialzied. So only one request can work at a time, so when you inside the Orcale code, nothing else will happen. On Unix, other tasks still contiunue, while the database query perl code is executed. Gerald -Ed Doesn't seem to have hindered it in any way for me. Linus has discussed raw partitions several times - the upshot being that they tend to be no faster than using e2fs because e2fs is very fast anyway, and you'd simply have to implement a lot of the e2fs functions inside of your database anyway. Anyhow - I don't know about all the internal workings of these things - just that it works and is damn quick for me. BTW: Someone benchmarked Oracle on Linux vs Oracle on NT (using TPC code) and found the Linux version to be about 4-7 (depending on the test) times faster. So I guess that's a finger in the eye to raw partitions (I think the NT version can use raw partitions - correct me if I'm wrong). -- Matt/ Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
RE: Embperl/Win32 offline problem
Hi, Embperl (1.2b6) in Randy Kobes' Win32 distribution doesn't work offline with following error: Can't load 'C:\PERL\site\5.00503\lib/MSWin32-x86/auto/HTML/Embperl/Embperl.dll' for module HTML::Embperl: load_file:Nelze nalzt jeden z knihovnch soubor potebnch pro sputn tto aplikace at C:\PERL\5.00503\lib/MSWin32-x86/DynaLoader.pm line 169. at C:\Projekty\ucetnispol\novy\convert.pl line 1 BEGIN failed--compilation aborted at C:\Projekty\ucetnispol\novy\convert.pl line 1. Process completed with exit code 2 convert.pl = use HTML::Embperl; use strict; use vars qw/@pages @languages/; = The missing Embperl.dll is of course there and under Apache/mod_perl Embperl works just fine. Yes, but the Embperl.dll is linked to the ApacheCore.dll, which is not found when running offline. Putting the directory where ApacheCore.dll is on your system inside the PATH, should solve the problem. Gerald --- Gerald Richter ecos electronic communication services gmbh Internet - Infodatenbanken - Apache - Perl - mod_perl - Embperl E-Mail: [EMAIL PROTECTED] Tel:+49-6133/925151 WWW:http://www.ecos.de Fax:+49-6133/925152 ---
Re: Embperl/Win32 offline problem (solved)
Gerald Richter wrote: Embperl (1.2b6) in Randy Kobes' Win32 distribution doesn't work offline with following error: Can't load 'C:\PERL\site\5.00503\lib/MSWin32-x86/auto/HTML/Embperl/Embperl.dll' for module HTML::Embperl: load_file:Nelze nalzt jeden z knihovnch soubor potebnch pro sputn tto aplikace at C:\PERL\5.00503\lib/MSWin32-x86/DynaLoader.pm line 169. ... Yes, but the Embperl.dll is linked to the ApacheCore.dll, which is not found when running offline. Putting the directory where ApacheCore.dll is on your system inside the PATH, should solve the problem. Thank you, now it works. - Robert
Re: authentication via login form
"Randal L. Schwartz" wrote: "Jeffrey" == Jeffrey W Baker [EMAIL PROTECTED] writes: Jeffrey Cookies are an acceptable way to make the browser remember Jeffrey something about your site. Speak for yourself. I'd change that to "... one possible way ..." instead of "acceptable way", and add "... for a single session". Cookies are evil when used for long-term identification. There is no one-to-one correspondance between a user and a browser, and yet cookies presume so. In a given week, I might use four or five browsers, and a few of those will be in public places, like libraries or client's sites. Randal, how do you suppose that HTTP basic auth works? The user agent stores the username and password and transmits them to the server on every request. This is exactly identical to a cookie which is set to have a short expiration time. That's why I say replacing basic auth with cookies is acceptable: both of them are a totally inadequate way to authenticate users. -jwb
RE: new for embperl...
If you stop Apache, delete your error log and the start Apache again. Are you still see these warning? GErald I restart the apache and delete an error log file and comment PerlFreshRestart out from the httpd.conf. Then, I get the error after I called the page like... [Sun Oct 10 12:47:55 1999] [error] [client 129.174.124.121] File does not exist: /usr/local/apache/htdocs/emperl/eg/x/loop.htm Best regards, --appsle
Re: authentication via login form
Andrew McNaughton wrote: Gunther Birznieks [EMAIL PROTECTED] wrote: [2] Mangled URL Paths Isn't it possible to browse the history on the harddrive... so is this really more secure than non-persistent cookies? Relying on browser based client side expiration is not a good idea, either for cookies or for mangled URL's. Yes! I hope those of you who attended my short crash course on session management at the O'Reilly conference took at least this one thing away: if you need security, you must not ever trust information you get from the client. Never, ever, ever. Either you store information about when the user identifier (cookie or url component) was last used on the server, or you put expiration information in the cookie content along with a cryptographically secure checksum (as described in the modperl book). You must check the expiry time for every authenticated hit. In my opinion storing anything besides a session key on the client side is needless extra work. Just give the client a token, in the cookie or in the URL, and make sure the client sends that token back on every request. Store the expriration time, the user name, and other information about the session on the server. Check and update this information on every request. Make the client reauthenticate after a short period of inactivity (15 minutes, perhaps), and give the user a way to logout or otherwise destroy their session (in case they are on a public terminal). So what is the security advantage of mangled URLs over cookies for authentication? I can't think of any security reason, but mangled URLs are more likely to work, you can bookmark them and get your session back at some other time, etc. There are huge threads on cookies vs. URLs in the archives. Cheers, Jeffrey
Re: authentication via login form
Spidaman The Defenestrator wrote: The point that should be taken is that if one must use a cookie for auth, expire it early and often. What would _really_ be nice is if there were a javascript or ecmascribble or whatever it's called object that can _set_ or _unset_ the auth request headers so one _could_ do a form driven authentication that used HTTP standards (basic and digest authentication). In that case wouldn't you be trusting the user-agent to respect the unset command? -jwb
Re: authentication via login form
Many thanks to all who replied. 1. I think I can summarize the responses so far as boiling down to how I do session management (hidden fields, URL mangling, cookies) and that I will have to develop my own authentication mechanism. (The reason I hoped there might be a solution using Apache's standard authentication mechanism is because users with login credentials will also be able to access a message board which which uses Basic authentication to validate them). 2. URL-based sessions are tempting (work with cookie-less browsers), but seem a headache to implement site-wide, tho it might just be my inexperience with them speaking here. 3. I am going to be using HTML::Mason for this site, so I will probably use Apache::Session for session management with cookies. By the way, the article that Jeffrey pointed me to (http://www.modperl.com/book/chapters/ch6.html#Cookie_Based_Access_Control) is very interesting - I ordered a copy of the book after reading it. Thanks again. -- Eugene
problem with Embperl and Apache::Session::File
Folks,
I'm running:
Solaris 2.6
Perl 5.005_03
Apache-Session-1.04
HTML_Embperl-1.2b10
and I'm trying to use Apache::Session::File ... I have this test program:
#!/usr/local/perl5.005_03/perl
use Apache;
use Apache::Session::File;
my $id = 1;
my $opts = { Directory =gt; '/tmp' };
my %session;
tie %session,'Apache::Session::File', $id, $opts;
print Content-type: text/plain\n\n;
if ($session{data} eq '') {
print "first time";
} else {
print "not first time";
}
$session{data} = 'x';
untie(%session);
exit;
and am getting this error message:
Invalid argument at
/usr/local/perl5.005_03/lib/site_perl/5.005/Apache/Session/SysVSemaphoreLocker.pm line
46.
Anyone know why this is happening? Thanks for your help,
Dave Saunders
[EMAIL PROTECTED]
Re: problem with Embperl and Apache::Session::File
"David R. Saunders" wrote:
Folks,
I'm running:
Solaris 2.6
Perl 5.005_03
Apache-Session-1.04
HTML_Embperl-1.2b10
and I'm trying to use Apache::Session::File ... I have this test program:
#!/usr/local/perl5.005_03/perl
use Apache;
use Apache::Session::File;
my $id = 1;
my $opts = { Directory =gt; '/tmp' };
my $opts = { Directory = '/tmp', NSems = 16 };
-jwb
finding real path to same server uri's
To make a long story short, is there a way in mod_perl to do something like... $r-real_path( 'http://some.virtual.domain/whatever/page/there.is' ) The cut-to-the-chase version is, I need to know the filename of a referer page originating on this server. (Yes, there are virtuals involved, and yes there are numerous aliases.) Rick Myers[EMAIL PROTECTED] The Feynman Problem 1) Write down the problem. Solving Algorithm 2) Think real hard. 3) Write down the answer.
