Re: NTLM module
You may check Apache::Access module at http://modperl.home.att.net in which I tried to provide a general solution to several popular authentication issuers such as SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. I think you missed the point (or I missunderstood your module): The problem is not doing the authentication against whatever, but doing NTLM authetication. With NTLM auth you don't get a password from the client, so how would compare the password that you don't have against SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. ? The only solution is to reimplement the challage/response that NTLM does. (The module Authen::Perl::NTLM maybe helpfull here). To do this you need either the password in clear text to compute the nt password hash (a sort of md4 hash) or the precomputed nt password hash. You won't have this with LDAP, IMAP, NIS, FTP, LWP and DBI etc Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - Cheers. Peter Bi - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 12, 2002 9:12 PM Subject: Re: NTLM module According to the documentation, if you set NTMLauthoritative to off, then if NTLM authorization fails, then it should pass it on to the lower level modules. Yes, that's true and it works like you describe it. The point that you are missing is (and that I have tried to show in my last mail), that during NTLM authentication there is no password! NTLM never passes the password to the server, so also the control gets passed to the lower level module, this lower level module must be able to handle NTLM. The default Apache auth handler isn't able to do so. It expects a password, which it doesn't gets because the client never has send it. Hope it's a little bit more clear now Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - I have cut out the below section from the doco which relates to the above functionality : =head2 PerlSetVar ntlmauthoritative Setting the ntlmauthoritative directive explicitly to 'off' allows authentication to be passed on to lower level modules if AuthenNTLM cannot autheticate the userand the NTLM authentication scheme is used. If set to 'on', which is the default, AuthenNTLM will try to verify the user andif it fails will give an Authorization Required reply. =head2 PerlSetVar basicauthoritative Setting the ntlmauthoritative directive explicitly to 'off' allows authentication to be passed on to lower level modules if AuthenNTLM cannot autheticate the userand the Basic authentication scheme is used. If set to 'on', which is the default, AuthenNTLM will try to verify the user andif it fails will give an Authorization Required reply. From the above description, I am hoping for the following events to take place - ntlm authentication (if fail this level go to next authentication) - basic authentication (if fails this level go to other authentication systems) - read passwords in htpasswd file ( if this fails, then access not granted) To enable the following behaviour, I have included the following directives in httpd.conf. - ntlmauthoritative off - basicauthoritative off I have also taken out the basic authentication to see if this works ie Authtype ntlm (not basic) But this still does fail allow the htpasswd system to verify access. If there are changes that need to be made to the AuthenNTLM.pm, I am not very well read in this area - are there any goof references. From my novice perspective, it appears that when NTLM is included as part of the authentication, the ability for normal modules to verify access (ie htpasswd file) is no longer available ie the perl module does not pass back what the standard modules are expecting. I am sorry to be a bit unclear in my analysis, but I am fairly new to apache perl modules. Many Thanks Adam original email attached -Original Message- From: Gerald Richter [mailto:[EMAIL PROTECTED]] Sent: Monday, 12
Re: NTLM module
Gerald: if you check the source of the Smb implemenation of the module, you would see that it performs basically the same function as NTLM. I agree with you that it does not fit the Microsoft definition of NTLM, so it is not a NTLM implementation. If ones purpose is to pass the protection by providing a valid username/password pair in a NT domain, then one does not have to follow that definition and the current Smb implementation is one of the possible solutions. Peter - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 12:53 AM Subject: Re: NTLM module You may check Apache::Access module at http://modperl.home.att.net in which I tried to provide a general solution to several popular authentication issuers such as SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. I think you missed the point (or I missunderstood your module): The problem is not doing the authentication against whatever, but doing NTLM authetication. With NTLM auth you don't get a password from the client, so how would compare the password that you don't have against SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. ? The only solution is to reimplement the challage/response that NTLM does. (The module Authen::Perl::NTLM maybe helpfull here). To do this you need either the password in clear text to compute the nt password hash (a sort of md4 hash) or the precomputed nt password hash. You won't have this with LDAP, IMAP, NIS, FTP, LWP and DBI etc Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - Cheers. Peter Bi - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 12, 2002 9:12 PM Subject: Re: NTLM module According to the documentation, if you set NTMLauthoritative to off, then if NTLM authorization fails, then it should pass it on to the lower level modules. Yes, that's true and it works like you describe it. The point that you are missing is (and that I have tried to show in my last mail), that during NTLM authentication there is no password! NTLM never passes the password to the server, so also the control gets passed to the lower level module, this lower level module must be able to handle NTLM. The default Apache auth handler isn't able to do so. It expects a password, which it doesn't gets because the client never has send it. Hope it's a little bit more clear now Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - I have cut out the below section from the doco which relates to the above functionality : =head2 PerlSetVar ntlmauthoritative Setting the ntlmauthoritative directive explicitly to 'off' allows authentication to be passed on to lower level modules if AuthenNTLM cannot autheticate the userand the NTLM authentication scheme is used. If set to 'on', which is the default, AuthenNTLM will try to verify the user andif it fails will give an Authorization Required reply. =head2 PerlSetVar basicauthoritative Setting the ntlmauthoritative directive explicitly to 'off' allows authentication to be passed on to lower level modules if AuthenNTLM cannot autheticate the userand the Basic authentication scheme is used. If set to 'on', which is the default, AuthenNTLM will try to verify the user andif it fails will give an Authorization Required reply. From the above description, I am hoping for the following events to take place - ntlm authentication (if fail this level go to next authentication) - basic authentication (if fails this level go to other authentication systems) - read passwords in htpasswd file ( if this fails, then access not granted) To enable the following behaviour, I have included the following directives in httpd.conf. - ntlmauthoritative off - basicauthoritative off I have also taken out the basic authentication to see if
RE: variables not changing with modperl??
I'm sure someone will correct me if I'm wrong... But, variables in the initial section (ie outside of a function) in the main package will stay in scope all the time. This means that it will retain the value from a previous request- which might be giving you these problems. As Perrin Harkins wrote, there are various solutions documented in the FAQ. You need to read these and follow one of the methods. Read this: http://perl.apache.org/docs/general/perl_reference/perl_reference.html#my___ Scoped_Variable_in_Nested_Subroutines - Perrin Personally I use the CGI::Application framework, which I find gives a really nice framework to develop applications in. Each application is a package, and each run mode is a sub which means you don't get any of these scope problems. Good luck, David. Maer neges e-bost hon ac unrhyw ffeiliau sydd ynghlwm wrthi yn gwbl gyfrinachol ac wediu bwriadu at sylw yr unigolyn neur endid y maent wedi eu cyfeirio ato yn unig. Gallant gynnwys gwybodaeth syn freintiedig yn gyfreithiol a/neun gyfrinachol ac os nad chi ywr sawl y cyfeiriwyd y neges ato, yna peidiwch â chopio, dosbarthu na chymryd unrhyw gamau o ganlyniad a gan ddibynnu arni. Os ydych wedi derbyn y neges e-bost hon ar gam, a wnewch chi ein hysbysu o hyn cyn gynted â phosib ai dileu os gwelwch yn dda. Barn neu safbwyntiaur awdur ywr rhai a fynegir yn y neges e-bost hon ac/neun unrhyw atodiadau ac nid ydynt yn adlewyrchu o anghenraid barn neu safbwyntiau S4C. This e-mail message and any files attached are strictly confidential and intended solely for the attention of the person or entity to whom they are addressed. They may contain legally privileged and/or confidential information and if you are not the addressee, you should not copy, distribute nor take any action in reliance on them. If you have received this e-mail message in error, please notify us as soon as possible and delete it. The views and opinions expressed in this e-mail message and any attachments are the authors own and they do not reflect necessarily the views and opinions of S4C.
OpenInteract 1.41 released
A new version (1.41) of OpenInteract has been released to CPAN. OpenInteract is an extensible web application server built on Apache, mod_perl, the Template Toolkit and SPOPS object persistence. This is a fairly minor upgrade -- a few bugfixes and refactorings, plus the ability to use a centralized repository for your custom templates so they will not get overwritten with package upgrades. As always, the other modifications in this release are listed in the 'Changes' file. Source (also via CPAN): http://prdownloads.sourceforge.net/openinteract/OpenInteract-1.41.tar.gz?download Detailed changes: http://sourceforge.net/project/shownotes.php?release_id=104968 Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: variables not changing with modperl??
* Michael Drons [EMAIL PROTECTED] [2002-08-13 01:55]:
Thanks for the link. I actually don't use functions.
Everything is mostly in MAIN. Here is a snip of code:
#!/usr/bin/perl -wT
use strict;
print body;
my $r = Apache-request;
$r-content_type(text/html);
$r-status(200);
my $auth_type = $r-auth_type;
$cookie=$auth_type-key;
($user,$hash)=split(/:/,$cookie);
read(STDIN, my $buffer, $ENV{'CONTENT_LENGTH'});
my @pairs = split(//, $buffer);
foreach my $pair (@pairs) {
}
What I am doing wrong? Everytime the script runs the
values of the variables coming in change. Should I
use the delete function and delete all of the
variables at the end of the script? @pairs is what
should change, but sometimes does not. I have tried
to add a undef @pairs before the split, but no luck.
Are you sure that this is the code that is running? It doesn't compile:
$ perl
#!/usr/bin/perl -wT
use strict;
print body;
my $r = Apache-request;
$r-content_type(text/html);
$r-status(200);
my $auth_type = $r-auth_type;
$cookie=$auth_type-key;
($user,$hash)=split(/:/,$cookie);
read(STDIN, my $buffer, $ENV{'CONTENT_LENGTH'});
my @pairs = split(//, $buffer);
foreach my $pair (@pairs) { }
Global symbol $cookie requires explicit package name at - line 7.
Global symbol $user requires explicit package name at - line 8.
Global symbol $hash requires explicit package name at - line 8.
Global symbol $cookie requires explicit package name at - line 8.
Execution of - aborted due to compilation errors
Make those global symbols ($cookie, $user, and $hash) lexical (declare
with my) and the code will both compile and do what you expect (i.e.,
not maintain values from call to call).
You'll also want to print things *after* you set the content type and
status, not before.
(darren)
--
The biggest difference between time and space is that you can't
reuse time.
-- Merrick Furst
Re: variables not changing with modperl??
Hi darren
Did you try starting apache with "httpd -X". It spawns only one process and that helps keep things inorder, as far as variable values. You can try trouble shooting with that.
darren chamberlain <[EMAIL PROTECTED]>wrote:
* Michael Drons <[EMAIL PROTECTED]>[2002-08-13 01:55]: Thanks for the link. I actually don't use functions. Everything is mostly in MAIN. Here is a snip of code: #!/usr/bin/perl -wT use strict; print ""; my $r = Apache-request; $r-content_type("text/html"); $r-status(200); my $auth_type = $r-auth_type; $cookie=$auth_type-key; ($user,$hash)=split(/:/,$cookie); read(STDIN, my $buffer, $ENV{'CONTENT_LENGTH'}); my @pairs = split(//, $buffer); foreach my $pair (@pairs) { } What I am doing wrong? Everytime the script runs the values of the variables coming in change. Should I use the delete function and delete all of the variables at the end of the script? @pairs is what should change, but sometimes does not. I have tried to add a undef @pairs before the split, but no luck.Are you sure that this is the code that is running? It doesn't compile:$ perl#!/usr/bin/perl -wTuse strict;print "";my $r = Apache-request;$r-content_type("text/html");$r-status(200);my $auth_type = $r-auth_type;$cookie=$auth_type-key;($user,$hash)=split(/:/,$cookie);read(STDIN, my $buffer, $ENV{'CONTENT_LENGTH'});my @pairs = split(//, $buffer);foreach my $pair (@pairs) { }Global symbol "$cookie" requires explicit package name at - line 7.Global symbol "$user" requires explicit package name at - line 8.Global symbol "$hash" requires explicit package name at - line 8.Global symbol "$cookie" requires explicit package name at - line 8.Execution of - aborted due to compilation errorsMake those global symbols ($cookie, $user, and $hash) lexical (declarewith my) and the code will both compile and do what you expect (i.e.,not maintain values from call to call).You'll also want to print things *after* you set the content type andstatus, not before.(darren)--The biggest difference between time and space is that you can'treuse time.-- Merrick FurstDo You Yahoo!?
HotJobs, a Yahoo! service - Search Thousands of New Jobs
Re: variables not changing with modperl??
darren chamberlain wrote: Make those global symbols ($cookie, $user, and $hash) lexical (declare with my) and the code will both compile and do what you expect (i.e., not maintain values from call to call). That's what I was thinking too. Also, it's really not a good idea to do your own parsing of the input and cookies. You should use one of the CGI modules or Apache::Request and Apache::Cookie for this. Writing your own routine for this is just asking for security problems and bugs. - Perrin
Re: variables not changing with modperl??
Sorry, There is a my in front of the ($cookie,$user)
code. I am confused about your second statement about
parsing the input. What should I be doing? Do you
mean I should use $r-read($content,
$r-header_in('Content-length'))? to read in the
variables?
I use the AuthCookie modules to set the cookies and to
authenicate.
Mike
--- Perrin Harkins [EMAIL PROTECTED] wrote:
darren chamberlain wrote:
Make those global symbols ($cookie, $user, and
$hash) lexical (declare
with my) and the code will both compile and do
what you expect (i.e.,
not maintain values from call to call).
That's what I was thinking too. Also, it's really
not a good idea to do
your own parsing of the input and cookies. You
should use one of the
CGI modules or Apache::Request and Apache::Cookie
for this. Writing
your own routine for this is just asking for
security problems and bugs.
- Perrin
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
Re: variables not changing with modperl??
On Tue, 13 Aug 2002, Michael Drons wrote:
Date: Tue, 13 Aug 2002 07:46:16 -0700 (PDT)
From: Michael Drons [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Perrin Harkins [EMAIL PROTECTED],
darren chamberlain [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: variables not changing with modperl??
Sorry, There is a my in front of the ($cookie,$user)
code. I am confused about your second statement about
parsing the input. What should I be doing? Do you
mean I should use $r-read($content,
$r-header_in('Content-length'))? to read in the
variables?
Michael,
In one of your posts, you included the following code:
#!/usr/bin/perl -wT
use strict;
print body;
my $r = Apache-request;
$r-content_type(text/html);
$r-status(200);
my $auth_type = $r-auth_type;
$cookie=$auth_type-key;
($user,$hash)=split(/:/,$cookie);
read(STDIN, my $buffer, $ENV{'CONTENT_LENGTH'});
my @pairs = split(//, $buffer);
foreach my $pair (@pairs) {
}
There is no my in front of $cookie or $user variables. If you are
lexically scoping them somewhere else in your script, please include
enough of an example for us to help you.
I use the AuthCookie modules to set the cookies and to
authenicate.
As for this and Perrin's comment about parsing on your own, the point
is that you've written a lot of code that has already been written and
debugged by a lot of really smart people. There's no reason for you
to be reading STDIN and spliting and all that. If you're using
mod_perl, then you really should do yourself a favor and read up on
Apache::Request and Apache::Cookie for doing all this stuff. It's
much faster (it's written in c), safer (it's been debugged), easier
(just install the module), and standard (i.e., more maintainable).
Of course, some people say that the nice thing about standards is that
there are so many to choose from. :)
ky
RE: can't fine ModuleConfig.c.
On Mon, 12 Aug 2002, Goehring, Chuck Mr., RCI - San Diego wrote: Randy, I'm using Perl 5.6.0 for this. Should I be using 5.8.0? Does that affect ModuleConfig.c? There may be some advantages to using 5.8.0 with mod_perl-2 on Win32, but 5.6.1 should be fine with mod_perl-1. Having problems running things with the version I put out last week. It complains about the dumbest things and is overly strict. Thanks Chuck What sort of things appear in the error log? Is it possible to give a short example which exhibits the problem? -- best regards, randy
Re: variables not changing with modperl??
Ken Y. Clark wrote: As for this and Perrin's comment about parsing on your own, the point is that you've written a lot of code that has already been written and debugged by a lot of really smart people. There's no reason for you to be reading STDIN and spliting and all that. If you're using mod_perl, then you really should do yourself a favor and read up on Apache::Request and Apache::Cookie for doing all this stuff. Even if you are just using CGI, you shouldn't write your own parsing code like this. Rather than try to explain why, I'll point you to this article on the subject: http://perlmonks.org/index.pl?node_id=51012 - Perrin
Compiling problems with Apache 2.040 (Win32)and mod_perl2 last version.
Hi NG. I has here the current Apache 2.040 for Win32. With compile of the last mod_perl2 version, get I the following error message. #-#-#-#-##-#-#-#-#-#-#-# cl -IG:/cygwin/tmp/modperl5/src/modules/perl -IG:/cygwin/tmp/modperl5/xs -IG:\Apache2/include -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -D HAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READF IX -IG:\Perl\lib\CORE -DMOD_PERL -O1 -MD -DNDEBUG -c mod_perl.c G:\Perl\ bin\perl.exe -IG:\Perl\lib -IG:\Perl\lib -MExtUtils::Command -e mv mod_perl.obj mod_perl.lo mod_perl.c G:\Perl\lib\CORE\perl.h(23) : warning C4005: 'VOIDUSED' : Makro-Neudefinition G:\Perl\lib\CORE\config.h(3118) : Siehe vorherige Definition von 'VOIDUS ED' mod_perl.c(511) : warning C4047: 'function' : Anzahl der Dereferenzierungen bei 'int (__cdecl *)(struct ap_filter_t *)' und 'int ' unterschiedlich mod_perl.c(511) : warning C4024: 'ap_register_output_filter' : Unterschiedliche Typen fuer formalen und uebergebenen Parameter 3 mod_perl.c(511) : error C2198: 'ap_register_output_filter' : Nicht genuegend Par ameter uebergeben mod_perl.c(515) : warning C4047: 'function' : Anzahl der Dereferenzierungen bei 'int (__cdecl *)(struct ap_filter_t *)' und 'int ' unterschiedlich mod_perl.c(515) : warning C4024: 'ap_register_input_filter' : Unterschiedliche T ypen fuer formalen und uebergebenen Parameter 3 mod_perl.c(515) : error C2198: 'ap_register_input_filter' : Nicht genuegend Para meter uebergeben mod_perl.c(519) : warning C4047: 'function' : Anzahl der Dereferenzierungen bei 'int (__cdecl *)(struct ap_filter_t *)' und 'int ' unterschiedlich mod_perl.c(519) : warning C4024: 'ap_register_output_filter' : Unterschiedliche Typen fuer formalen und uebergebenen Parameter 3 mod_perl.c(519) : error C2198: 'ap_register_output_filter' : Nicht genuegend Par ameter uebergeben mod_perl.c(523) : warning C4047: 'function' : Anzahl der Dereferenzierungen bei 'int (__cdecl *)(struct ap_filter_t *)' und 'int ' unterschiedlich mod_perl.c(523) : warning C4024: 'ap_register_input_filter' : Unterschiedliche T ypen fuer formalen und uebergebenen Parameter 3 mod_perl.c(523) : error C2198: 'ap_register_input_filter' : Nicht genuegend Para meter uebergeben NMAKE : fatal error U1077: 'cl' : Rueckgabe-Code '0x2' Stop. NMAKE : fatal error U1077: 'cd' : Rueckgabe-Code '0x2' Stop. #-#-#-#-#-#-#-# With Apache 2.039 (Win32) there are no problems. Possibly does someone have an idea? Thanks for each assistance. Stefan
-Wl,-E
Hello! I can't build apache 1.3.26 with mod_perl 1.27 on Solaris 2.8 I use: perl Makefile.pl APACHE_SRC=../apache1/src \ NO_HTTPD=1 USE_APACI=1 PREP_HTTPD \ EVERYTHING=1 and in apache directory: ./configure --activate-module=src/modules/perl/libperl.a here is the output: Configuring for Apache, Version 1.3.26 + using installation path layout: Apache (config.layout) + activated perl module (modules/perl/libperl.a) Creating Makefile Creating Configuration.apaci in src Creating Makefile in src + configured for Solaris 280 platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules o perl_module uses ConfigStart/End + mod_perl build type: OBJ + id: mod_perl/1.27 + id: Perl/v5.6.1 (solaris) [perl] + setting up mod_perl build environment + adjusting Apache build environment + enabling Perl support for SSI (mod_include) + using builtin Expat + checking sizeof various data types + doing sanity check on compiler and options ** A test compilation with your Makefile configuration ** failed. The below error output from the compilation ** test will give you an idea what is failing. Note that ** Apache requires an ANSI C Compiler, such as gcc. Error Output for sanity check cd ..; gcc -DSOLARIS2=280 -DMOD_PERL -DUSE_PERL_SSI -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FI LE_OFFSET_BITS=64 -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci` -I. -I/usr/local//lib/perl5/5.6.1/sun4-solaris /CORE-o helpers/dummy helpers/dummy.c -lsocket -lnsl -lpthread -Wl,-E -L/usr/local/lib /usr/local/lib/perl5/5.6.1/sun4-solaris/auto/DynaLoader/DynaLoader.a -L/usr/local/lib/perl5/5.6.1/sun4-solaris/CORE -lperl -lsocket -lnsl -ldl -lm -lc /usr/ccs/bin/ld: illegal option -- E usage: ld [-abc:d:e:f:h:il:mo:p:rstu:z:B:D:F:GI:L:M:N:P:Q:R:S:VY:] file(s) Does anybody know how to fix it? I tried MP_LD=gcc but with the same effect. thanks -i-
RE: can't fine ModuleConfig.c.
Randy, My server barfed and I had to re-format. Do you think I ought to go with Apache 2? I need to get to full time ssl to meet the security requirements anyway. I was planning to do this when I go hit with the need to close that vulnerability in Apache. Is the 2.0 ready for prime time on Win 2000? I really would like to get off this pathetic single-threaded arrangement with Apache 1.x. Thanks Chuck -Original Message- From: Randy Kobes [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 13, 2002 9:03 AM To: Goehring, Chuck Mr., RCI - San Diego Cc: mod perl list (E-mail) Subject: RE: can't fine ModuleConfig.c. On Mon, 12 Aug 2002, Goehring, Chuck Mr., RCI - San Diego wrote: Randy, I'm using Perl 5.6.0 for this. Should I be using 5.8.0? Does that affect ModuleConfig.c? There may be some advantages to using 5.8.0 with mod_perl-2 on Win32, but 5.6.1 should be fine with mod_perl-1. Having problems running things with the version I put out last week. It complains about the dumbest things and is overly strict. Thanks Chuck What sort of things appear in the error log? Is it possible to give a short example which exhibits the problem? -- best regards, randy
Re: Handler Concept / Question
You were close. It's default-handler. http://httpd.apache.org/docs/handler.html And in mod_perl docs: http://perl.apache.org/docs/1.0/guide/config.html#Overriding_E_lt_LocationE _gt__Setting_in__Sub_Location_ __ Thanks, that was what I was looking for. Thomas Whitney
Re: -Wl,-E
Ihor Bilyy wrote:
Hello!
I can't build apache 1.3.26 with mod_perl 1.27 on Solaris 2.8
I use:
/usr/ccs/bin/ld: illegal option -- E
usage: ld [-abc:d:e:f:h:il:mo:p:rstu:z:B:D:F:GI:L:M:N:P:Q:R:S:VY:] file(s)
Sun put out a patch to their linker (ld) that breaks the Configure script for
perl. It checks for a specific info string output from the ld command, and
decides from that if you are using Sun's ld, or the Gnu ld. Since that patch
changes the output of the ld command's info string, Configure thinks you are
using Gnu's ld, and hence sets up the Gnu ld options to pass to Sun's ld.
Obviously, this doesn't work. Sun has since fixed it, by another patch that puts
back the old info string in their ld.
The patch to ld that broke this is 109147-14. The 109147-16 patch fixes it
again.
Update these Solaris patches and your problem should go away. :)
--
David McCabe Network and Communications Services, McGill University
Montreal, Quebec, Canada [EMAIL PROTECTED]
In theory there is no difference between theory and practice.
In practice there is. -Yogi Berra
*** perl-5.6.1/hints/solaris_2.sh Thu Jan 31 13:55:18 2002
--- perl-5.6.1/hints/solaris_2.sh.orig Fri Jan 25 19:56:05 2002
***
*** 199,209
# egcs-1.0.3, GNU as 2.9.1 and GNU ld 2.9.1
# --Andy Dougherty [EMAIL PROTECTED]
# Tue Apr 13 17:19:43 EDT 1999
- # Patch 109147-14 for Solaris 8 (and probably same patch on other
- # versions, the Link Patch) changes a string that is output by ld and
- # checked for here. I added another elsif block to test for the new string.
- # David McCabe [EMAIL PROTECTED]
- # Friday Jan 25 20:02:00 EDT 2002
# Get gcc to share its secrets.
echo 'main() { return 0; }' try.c
--- 199,204
***
*** 244,252
# All Solaris versions of ld I've seen contain the magic
# string used in the grep.
:
- # NEW BLOCK FOR SOLARIS LINK PATCH - exception to above comment :)
- elif echo $verbose | grep ld: Solaris Link Editors: /dev/null 21; then
- :
else
# No evidence yet of /usr/ccs/bin/ld. Some versions
# of egcs's ld wrapper call /usr/ccs/bin/ld in turn but
--- 239,244
Re: NTLM module
if you check the source of the Smb implemenation of the module, you would see that it performs basically the same function as NTLM. I agree with you that it does not fit the Microsoft definition of NTLM, so it is not a NTLM implementation. If ones purpose is to pass the protection by providing a valid username/password pair in a NT domain, then one does not have to follow that definition and the current Smb implementation is one of the possible solutions. The point is not how the password is passed to the nt server, the point is how the browser and the web server exchange the credenticals. With basic auth and with your module the user enters a username and a password and you use different backends to verify this. With NTLM authentication the Internet Exploerer and the Web server uses a challange-response procdure to exchange credenticals (and IE does this without asking the user, so you get logged on with your windows username, which safes the user some extra typing). They never send the password over the wire, so you don't have a password to send/verify to your backend. What you talking about is the verification of the password between the web server and the nt domain controller, thats something different. Gerald Peter - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 12:53 AM Subject: Re: NTLM module You may check Apache::Access module at http://modperl.home.att.net in which I tried to provide a general solution to several popular authentication issuers such as SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. I think you missed the point (or I missunderstood your module): The problem is not doing the authentication against whatever, but doing NTLM authetication. With NTLM auth you don't get a password from the client, so how would compare the password that you don't have against SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. ? The only solution is to reimplement the challage/response that NTLM does. (The module Authen::Perl::NTLM maybe helpfull here). To do this you need either the password in clear text to compute the nt password hash (a sort of md4 hash) or the precomputed nt password hash. You won't have this with LDAP, IMAP, NIS, FTP, LWP and DBI etc Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - Cheers. Peter Bi - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 12, 2002 9:12 PM Subject: Re: NTLM module According to the documentation, if you set NTMLauthoritative to off, then if NTLM authorization fails, then it should pass it on to the lower level modules. Yes, that's true and it works like you describe it. The point that you are missing is (and that I have tried to show in my last mail), that during NTLM authentication there is no password! NTLM never passes the password to the server, so also the control gets passed to the lower level module, this lower level module must be able to handle NTLM. The default Apache auth handler isn't able to do so. It expects a password, which it doesn't gets because the client never has send it. Hope it's a little bit more clear now Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - I have cut out the below section from the doco which relates to the above functionality : =head2 PerlSetVar ntlmauthoritative Setting the ntlmauthoritative directive explicitly to 'off' allows authentication to be passed on to lower level modules if AuthenNTLM cannot autheticate the userand the NTLM authentication scheme is used. If set to 'on', which is the default, AuthenNTLM will try to verify the user andif it fails will give an Authorization Required reply. =head2 PerlSetVar basicauthoritative Setting the ntlmauthoritative directive explicitly to 'off' allows
Re: NTLM module
The username/password pair is sent only once to the issuer machine and the follow-up authentications are performed using a self-certified, time-limited, hash. In fact, it is based on access-control, having nothing to do with Basic Authentication. This is discussed in detail in the Eagle book. I am not sure if NTLM is even better but for most applications, it is pretty secure. Peter - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 12:29 PM Subject: Re: NTLM module if you check the source of the Smb implemenation of the module, you would see that it performs basically the same function as NTLM. I agree with you that it does not fit the Microsoft definition of NTLM, so it is not a NTLM implementation. If ones purpose is to pass the protection by providing a valid username/password pair in a NT domain, then one does not have to follow that definition and the current Smb implementation is one of the possible solutions. The point is not how the password is passed to the nt server, the point is how the browser and the web server exchange the credenticals. With basic auth and with your module the user enters a username and a password and you use different backends to verify this. With NTLM authentication the Internet Exploerer and the Web server uses a challange-response procdure to exchange credenticals (and IE does this without asking the user, so you get logged on with your windows username, which safes the user some extra typing). They never send the password over the wire, so you don't have a password to send/verify to your backend. What you talking about is the verification of the password between the web server and the nt domain controller, thats something different. Gerald Peter - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 12:53 AM Subject: Re: NTLM module You may check Apache::Access module at http://modperl.home.att.net in which I tried to provide a general solution to several popular authentication issuers such as SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. I think you missed the point (or I missunderstood your module): The problem is not doing the authentication against whatever, but doing NTLM authetication. With NTLM auth you don't get a password from the client, so how would compare the password that you don't have against SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. ? The only solution is to reimplement the challage/response that NTLM does. (The module Authen::Perl::NTLM maybe helpfull here). To do this you need either the password in clear text to compute the nt password hash (a sort of md4 hash) or the precomputed nt password hash. You won't have this with LDAP, IMAP, NIS, FTP, LWP and DBI etc Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - Cheers. Peter Bi - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 12, 2002 9:12 PM Subject: Re: NTLM module According to the documentation, if you set NTMLauthoritative to off, then if NTLM authorization fails, then it should pass it on to the lower level modules. Yes, that's true and it works like you describe it. The point that you are missing is (and that I have tried to show in my last mail), that during NTLM authentication there is no password! NTLM never passes the password to the server, so also the control gets passed to the lower level module, this lower level module must be able to handle NTLM. The default Apache auth handler isn't able to do so. It expects a password, which it doesn't gets because the client never has send it. Hope it's a little bit more clear now Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax:
Re: -Wl,-E
After applying that patches error message is the same.
ld -V:
ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.275
btw gcc --version 2.95.2, maybe problem is with gcc ?
-i-
- Original Message -
From: David McCabe [EMAIL PROTECTED]
To: Ihor Bilyy [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, August 13, 2002 3:11 PM
Subject: Re: -Wl,-E
Ihor Bilyy wrote:
Hello!
I can't build apache 1.3.26 with mod_perl 1.27 on Solaris 2.8
I use:
/usr/ccs/bin/ld: illegal option -- E
usage: ld [-abc:d:e:f:h:il:mo:p:rstu:z:B:D:F:GI:L:M:N:P:Q:R:S:VY:]
file(s)
Sun put out a patch to their linker (ld) that breaks the Configure script
for
perl. It checks for a specific info string output from the ld command, and
decides from that if you are using Sun's ld, or the Gnu ld. Since that
patch
changes the output of the ld command's info string, Configure thinks you
are
using Gnu's ld, and hence sets up the Gnu ld options to pass to Sun's ld.
Obviously, this doesn't work. Sun has since fixed it, by another patch
that puts
back the old info string in their ld.
The patch to ld that broke this is 109147-14. The 109147-16 patch fixes it
again.
Update these Solaris patches and your problem should go away. :)
--
David McCabe Network and Communications Services, McGill University
Montreal, Quebec, Canada [EMAIL PROTECTED]
In theory there is no difference between theory and practice.
In practice there is. -Yogi Berra
*** perl-5.6.1/hints/solaris_2.sh Thu Jan 31 13:55:18 2002
--- perl-5.6.1/hints/solaris_2.sh.orig Fri Jan 25 19:56:05 2002
***
*** 199,209
# egcs-1.0.3, GNU as 2.9.1 and GNU ld 2.9.1
# --Andy Dougherty [EMAIL PROTECTED]
# Tue Apr 13 17:19:43 EDT 1999
- # Patch 109147-14 for Solaris 8 (and probably same patch on other
- # versions, the Link Patch) changes a string that is output by ld and
- # checked for here. I added another elsif block to test for the new
string.
- # David McCabe [EMAIL PROTECTED]
- # Friday Jan 25 20:02:00 EDT 2002
# Get gcc to share its secrets.
echo 'main() { return 0; }' try.c
--- 199,204
***
*** 244,252
# All Solaris versions of ld I've seen contain the magic
# string used in the grep.
:
- # NEW BLOCK FOR SOLARIS LINK PATCH - exception to above comment :)
- elif echo $verbose | grep ld: Solaris Link Editors: /dev/null
21; then
- :
else
# No evidence yet of /usr/ccs/bin/ld. Some versions
# of egcs's ld wrapper call /usr/ccs/bin/ld in turn but
--- 239,244
apache + mod_perl -- chunk mode trailer
I have a problem with the HTTP response in the chunk mode using mod_perl. When apache sends a response in the chunk mode, the mod_perl handler invokes the ap_send_http_header() function in the apache src/main/http_protocol.c file, and the r-chunked flag is set to 1 (by the ap_keep_alive() function). However when apache calls the ap_finalize_request_protocol() before sending out the request, the r-chunked is 0. Indeed, all changes that mod_perl/perl script made to request_rec (r) does not show up there at the stage the ap_finalize_request_protocol function was called. That caused the chunked content trailer was not sent to the client. I am running the apache on SUN unix box. The apache version is 1.3.12 and set the (keepAlive on). The mod perl version is 1.24. Version 1.27 also has this problems as well. If you do an apache code trace, set the breakpoint at apache_src/main/http_protocol.c function ap_finalize_request_protocol, you will see the r-chunked == 0 even though it was set to be 1. You can also use snoop to see that the trailers \0\r\n was missing. Is this a well known bug? Any way to solve it? Tx... __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Compiling problems with Apache 2.040 (Win32)and mod_perl2 lastversion.
Stefan Sabolowitsch wrote: Hi NG. I has here the current Apache 2.040 for Win32. With compile of the last mod_perl2 version, get I the following error message. [...] mod_perl.c(511) : warning C4047: 'function' : Anzahl der Dereferenzierungen bei 'int (__cdecl *)(struct ap_filter_t *)' und 'int ' unterschiedlich mod_perl.c(511) : warning C4024: 'ap_register_output_filter' : Unterschiedliche Typen fuer formalen und uebergebenen Parameter 3 mod_perl.c(511) : error C2198: 'ap_register_output_filter' : Nicht genuegend Par ameter uebergeben [...] With Apache 2.039 (Win32) there are no problems. Possibly does someone have an idea? Try building with the cvs mod_perl version: http://perl.apache.org/docs/2.0/user/install/install.html#Installing_from_Source __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
naming convention
I have a proposed perl / modperl module that will go to CPAN Graphics::ColorPicker : A perl module for WYSIWYG web applications that allow selection of HEX color numbers I think this is an appropriate name, but have not submitted in this category before. Please advise. See: http://www.bizsystems.net/downloads/graphics/demo.html Thanks, Michael
Re: naming convention
Michael Robinton wrote: I have a proposed perl / modperl module that will go to CPAN Graphics::ColorPicker : A perl module for WYSIWYG web applications that allow selection of HEX color numbers I think this is an appropriate name, but have not submitted in this category before. Please advise. I guess that this module is not extending mod_perl functionality, but simply optionally uses it and therefore you better off discussing this at [EMAIL PROTECTED], [EMAIL PROTECTED] without even mentioning mod_perl so not to confuse people. If my guess is wrong (you provided too little info) and it *requires* mod_perl it should probably be named something like Apache::ColorPicker, but again, you've provided too little info to tell. See: http://www.bizsystems.net/downloads/graphics/demo.html FWIW, it doesn't seem to do anything on mozilla-1.0/linux. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: NTLM module
The username/password pair is sent only once to the issuer machine and the follow-up authentications are performed using a self-certified, time-limited, hash. In fact, it is based on access-control, having nothing to do with Basic Authentication. This is discussed in detail in the Eagle book. I am not sure if NTLM is even better but for most applications, it is pretty secure. NTLM is a bit more secure, but also this is not the point here. NTLM auth doesn't require you to enter your password at all. I don't argue that NTLM is better, it just fits better in some intranet situations, because the user doesn't have to type in the username/password. It's seems that I was not clear enough. The only thing I say is that under the precondition you want to use NTLM client authetication, you can't use the way your module verifies the password. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - Peter - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 12:29 PM Subject: Re: NTLM module if you check the source of the Smb implemenation of the module, you would see that it performs basically the same function as NTLM. I agree with you that it does not fit the Microsoft definition of NTLM, so it is not a NTLM implementation. If ones purpose is to pass the protection by providing a valid username/password pair in a NT domain, then one does not have to follow that definition and the current Smb implementation is one of the possible solutions. The point is not how the password is passed to the nt server, the point is how the browser and the web server exchange the credenticals. With basic auth and with your module the user enters a username and a password and you use different backends to verify this. With NTLM authentication the Internet Exploerer and the Web server uses a challange-response procdure to exchange credenticals (and IE does this without asking the user, so you get logged on with your windows username, which safes the user some extra typing). They never send the password over the wire, so you don't have a password to send/verify to your backend. What you talking about is the verification of the password between the web server and the nt domain controller, thats something different. Gerald Peter - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 12:53 AM Subject: Re: NTLM module You may check Apache::Access module at http://modperl.home.att.net in which I tried to provide a general solution to several popular authentication issuers such as SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. I think you missed the point (or I missunderstood your module): The problem is not doing the authentication against whatever, but doing NTLM authetication. With NTLM auth you don't get a password from the client, so how would compare the password that you don't have against SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. ? The only solution is to reimplement the challage/response that NTLM does. (The module Authen::Perl::NTLM maybe helpfull here). To do this you need either the password in clear text to compute the nt password hash (a sort of md4 hash) or the precomputed nt password hash. You won't have this with LDAP, IMAP, NIS, FTP, LWP and DBI etc Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - Cheers. Peter Bi - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 12, 2002 9:12 PM Subject: Re: NTLM module According to the documentation, if you set NTMLauthoritative to off, then if NTLM authorization fails, then it should pass it on to the
Re: naming convention
Stas wrote:
Michael Robinton wrote:
I have a proposed perl / modperl module that will go to CPAN
Graphics::ColorPicker : A perl module for WYSIWYG web
applications that allow selection of HEX color numbers
I think this is an appropriate name, but have not submitted in
this category before. Please advise.
I guess that this module is not extending mod_perl functionality,
but simply optionally uses it and therefore you better off
discussing this at [EMAIL PROTECTED], [EMAIL PROTECTED] without
even mentioning mod_perl so not to confuse people. If my guess is
wrong (you provided too little info) and it *requires* mod_perl it
should probably be named something like Apache::ColorPicker, but
again, you've provided too little info to tell.
Sorry bout that. It does optionally use mod_perl -- it tests
eval{require Apache} and proceeds, otherwise uses print statements to STDOUT
See: http://www.bizsystems.net/downloads/graphics/demo.html
FWIW, it doesn't seem to do anything on mozilla-1.0/linux.
hmm works fine on my mozilla-1.0/linux build #2001061002
tested on above + windoze MSIE5.5, Netscape 4.7, Mozilla 1.0
If you can tell me more that would be nice.
Michael
Re: NTLM module
Gerald: Any comment on Paulo's question ? (I am interested in that knowledge too.) I doubt that NTLM does not need any password. Logically, there must be a way to set up the initial trustful connection between two machines. If not password, what will that be ? Or something like Digital Authentication ? Peter - Original Message - From: [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 2:36 PM Subject: Re: NTLM module Am I totally wrong, or the plain and painful answer is that NTLM is only supported on Win32 boxes? I think I read somewhere that, because the module relies the Win32 API, it doesn't run on other systems. It even said something like ...whoever wants to grab some Samba code and port the module to *nix, please do Again, this is just something I guess I think I read somewhere, so take it with a grain of salt. Paulo Meireles MCSE (and not ashame of it) ;-) Como Reduzir os Riscos de Segurança da Sua Organização Whitepaper Gratuito sobre Serviços de Segurança http://www.vianetworks.pt/security/whitepaper_fs.html and - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 8:58 PM Subject: Re: NTLM module The username/password pair is sent only once to the issuer machine and the follow-up authentications are performed using a self-certified, time-limited, hash. In fact, it is based on access-control, having nothing to do with Basic Authentication. This is discussed in detail in the Eagle book. I am not sure if NTLM is even better but for most applications, it is pretty secure. NTLM is a bit more secure, but also this is not the point here. NTLM auth doesn't require you to enter your password at all. I don't argue that NTLM is better, it just fits better in some intranet situations, because the user doesn't have to type in the username/password. It's seems that I was not clear enough. The only thing I say is that under the precondition you want to use NTLM client authetication, you can't use the way your module verifies the password. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - Peter - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 12:29 PM Subject: Re: NTLM module if you check the source of the Smb implemenation of the module, you would see that it performs basically the same function as NTLM. I agree with you that it does not fit the Microsoft definition of NTLM, so it is not a NTLM implementation. If ones purpose is to pass the protection by providing a valid username/password pair in a NT domain, then one does not have to follow that definition and the current Smb implementation is one of the possible solutions. The point is not how the password is passed to the nt server, the point is how the browser and the web server exchange the credenticals. With basic auth and with your module the user enters a username and a password and you use different backends to verify this. With NTLM authentication the Internet Exploerer and the Web server uses a challange-response procdure to exchange credenticals (and IE does this without asking the user, so you get logged on with your windows username, which safes the user some extra typing). They never send the password over the wire, so you don't have a password to send/verify to your backend. What you talking about is the verification of the password between the web server and the nt domain controller, thats something different. Gerald Peter - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 12:53 AM Subject: Re: NTLM module You may check Apache::Access module at http://modperl.home.att.net in which I tried to provide a general solution to several popular authentication issuers such as SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. I think you missed the point (or I missunderstood your module): The problem is not doing the authentication against whatever, but doing NTLM
Re: naming convention
Michael Robinton wrote:
Stas wrote:
Michael Robinton wrote:
I have a proposed perl / modperl module that will go to CPAN
Graphics::ColorPicker : A perl module for WYSIWYG web
applications that allow selection of HEX color numbers
I think this is an appropriate name, but have not submitted in
this category before. Please advise.
I guess that this module is not extending mod_perl functionality,
but simply optionally uses it and therefore you better off
discussing this at [EMAIL PROTECTED], [EMAIL PROTECTED] without
even mentioning mod_perl so not to confuse people. If my guess is
wrong (you provided too little info) and it *requires* mod_perl it
should probably be named something like Apache::ColorPicker, but
again, you've provided too little info to tell.
Sorry bout that. It does optionally use mod_perl -- it tests
eval{require Apache} and proceeds, otherwise uses print statements to STDOUT
so my guess was right, take it to one of the lists I've mentioned for
the best effect. Here we discuss modules which extend or exclusively use
mod_perl.
See: http://www.bizsystems.net/downloads/graphics/demo.html
FWIW, it doesn't seem to do anything on mozilla-1.0/linux.
hmm works fine on my mozilla-1.0/linux build #2001061002
tested on above + windoze MSIE5.5, Netscape 4.7, Mozilla 1.0
If you can tell me more that would be nice.
I cannot tell you more, because it doesn't do anything ;). I enter
FA23DB as suggested, click on the button, and get a window whose source is
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01
Transitional//ENhtmlheadtitle/title/headbody/body/html
but we are going OT here, let's take it off the list.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
