Apache::AuthCookie 3.05 prerelease
I have placed a pre-release of Apache::AuthCookie 3.05 which supports mod_perl version 2 (as well as mod_perl version 1) up on the sorceforge downloads. The API has changed slightly for mod_perl version 2 in order to avoid using Apache-request. See the README.modperl2 file in the distribution for the detailed changes. The API has not changed in the version of the module for mod_perl 1.x. Obviously since the API has changed, and because this is the first release supporting mod_perl v2, this is an alpha release. This release is targeted at developers of AuthCookie subclasses that wish to port their subclasses to mod_perl2. If I do not get complaints about the AuthCookie API changes that I have made, I will upload this release to CPAN. You can get AuthCookie 3.05pre1 from: https://sourceforge.net/project/showfiles.php?group_id=12701 Regards, Michael Schout GKG.NET, INC
Re: Installing Apache::AuthCookie
On Tue, 10 Jun 2003, Jay Strauss wrote: I'm running into a problem during the make test while installing the current version of Apache::AuthCookie. I'm not sure where to go. I looked at tests 10 and 15: Hrm. You are supposed to get ok for all of the tests. If I had to guess from this I would say that there is something in your httpd.conf (that Apache::test is pulling the config from) that is screwing up the tests. Can you send me your t/httpd.conf? (privately, no need to send it to the list). Regards Michael -- Hal 9000 - Put down those Windows disks Dave Dave? DAVE!!
Re: OO handlers
Geoffrey Young wrote:
interesting. the last time I tried was with bleedperl before 5.8 was
released - I know it worked then because I was writing a patch for
mod_perl core based on it. this thread has most of the dialogue:
Hrm. Well, not sure how the :method attribute is implemented, but what
I was trying to do was create a :Profiled attribute handler. So in my
base class I had:
use Attribute::Handlers;
sub Profiled ATTR(CODE) { ... }
and in a subclass:
sub foo :Profiled {
}
but I was never able to get the Profiled handler to get called. I
looked into Attribute::Handlers and it has INIT and CHECK blocks that
set up the handlers in it, so I suspected this might be the problem.
Doug claims that CHECK blocks dont work because perl calls CHECK blocks
during perl_parse(), which only happens once at startup. So he said
that it doesnt work for the same reason that:
perl -e 'eval qq(CHECK { print hello world })'
doesnt work.
I tried just putting a CHECK block with a warn in my application, and it
is true that the the CHECK block never gets called. So given that it
seems impossible that the Attribute::Handlers module can work under
mod_perl.
Given that though, I dont doubt that the :method handler works for you
:). Maybe this is implemented as a special case in mod_perl??
Mike
Re: Getting the server to parse files after the handler has doneits work...
Luis Fagundes wrote: I think you can only do this in Apache 2.0. In Apache 1.3 you can chain perl modules with OutputChain, but you can't chain a perl module and another apache module. You CAN do this in 1.3 using Apache::Filter and Apache::SSI. I replied privately to Simran pointing him to these modules, but forgot to CC the list. Anyway, just wanted to clarify to the list that this is definately possible with 1.3 in case others were curious :). Regards, Mike
Re: OO handlers
Geoffrey Young wrote:
keep in mind that neither book mentions the use of subroutine
attributes, which is allowed in 1.3 but the only way in 2.0
sub handler : method {
...
}
I am 99% sure that Attribute handlers wont work in 1.3 because
Attribute::Handlers use CHECK{} blocks to set up the handlers. CHECK
blocks do not work in mod_perl under Apache 1.3 (search the list
archives for the reason). So because CHECK blocks never execute in
mod_perl under Apache 1.3 attribute handlers wont work. I tried to get
them work in under Apache 1.3 a few months ago, and gave up because of
the CHECK restrictions.
Mike
Re: [OTish] Version Control?
perl Makefile.PL /dev/null works for us. We encapsulate it in a macro (see below). Now why didn't I think of that? :). This works nicely. We still ahve to patch some of the individual Makefile.PL's, but that is acceptable (some of them have exit; at the end of them for example which causes the Makefile generation to stop :)). We use a vendor branch to import the new versions of modules as we update, and CVS handles this fairly well. Mike
Re: [OTish] Version Control?
Okay, I'll chime in on this one. I work on a medium sized mod_perl project (approximately 50,000 lines of perl code). This project is managed similarly to to the setups that have been described so far. We store all of our CPAN module sources in CVS, and currently we distribute the modules to the servers via RPM. Its critical that we maintian sources to the CPAN modules in CVS because some modules have to be patched to make the modules work for this particular project (and some modules just plain have bugs :)). The modules get installed in the main perl directory (e.g.: /usr/lib/perl5). We use cvs branches to manage releases and development versions of the web site and perl code. When we get to a realease point we make a branch (e.g.: RELEASE-1_0), and html developers continue working on that branch for changes to the currently released site. The web servers can be updated with simply cvs update this way. On the main trunk perl/web development continues until the next release happens. However, due to the fact that the CPAN modules are distributed via RPM, there are various incompatibility problems that come up. For example, one time we upgraded Apache::Filter between releases. Unfortunately, the old version was not compatible with the new version, so a single machine could run either the current release branch, or the development branch, but not both simultaneously (because Apache::Filter was incomptaible and was installed under /usr/lib/perl5). So currently we are looking into also installing CPAN modules under the project directory and managing the binary CPAN modules CVS, which would solve this problem. Developers could check out a sandbox of the release branch and they would get the modules that belong to that release (binary compatibility is okay because our development machines match the production machines). The management nightmare to all of this is that automating the build process for lots of CPAN modules (rougly 110 of them) is painful. Our CPAN source tree looks something like this: project-support/ src/ Makefile Apache-Filter/ CGI/ Digest-MD5/ ... First we tried making a Makefile.PL in src that used the DIR attribute of WriteMakefile to specify the subdirs to build all of the modules. THis didnt work so well. The problems with this are: 1) some Makefile.PL's refuse to generate a Makefile if PREREQ_PM's are not satisfied (if we haven't built them yet) 2) some Makefile.PL's are INTERACTIVE, and you cant turn it off (e.g.: Apache::Filter requires you to hit Return a number of times at a MINIMUM. So we resorted to a set of overly-complicated GNUmakefiles that would generate Makefile's from Makefile.PL's, and these would set PERL5LIB to find the dependencies (e.g.: DBD-Pg would put ../DBI/blib into PERL5LIB). I'm not convinced this is the best way to go about it, but it sort of works. How does everyone else cope with this (managing trees of CPAN modules / CPAN module tree build environments)? Maybe we are sort of unique in that we use so many 3rd part CPAN modules, but because we use so many of them its pretty critical that we manage them in CVS. Mike
Re: [RFC] Apache-GeoIP module
darren chamberlain wrote: attached to Apache. I'd like to see, in addition to the Apache stuff, a generic GeoIP library that can be used from outside Apache, like in log-eating scripts. You mean like this? http://search.cpan.org/author/TJMATHER/Geo-IP-0.26/lib/Geo/IP.pm :) Mike
Re: [RFC] Apache-GeoIP module
darren chamberlain wrote: One thing I'd add if you do decide to use the Geo::IP module, it does not behave as documented if it does not find a match. The docs say it returns undef, but in fact it returns the string --. The attached patch fixes that problem. I've sent the patch to the GeoIP folks, and got no reply. I'll try sending it to [EMAIL PROTECTED] and see if someone gets it that way :). Mike Index: IP.xs === RCS file: /usr/local/cvsroot/gkgnsi-support/src/Geo-IP/IP.xs,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- IP.xs 22 Aug 2002 20:30:43 - 1.1 +++ IP.xs 22 Aug 2002 20:32:55 - 1.2 @@ -39,8 +39,14 @@ country_code_by_addr(gi, addr) GeoIP *gi char * addr +PREINIT: +char * code; CODE: - RETVAL = (char *)GeoIP_country_code_by_addr(gi,addr); + code = (char *)GeoIP_country_code_by_addr(gi,addr); +if (*code == '-') +RETVAL = NULL; +else +RETVAL = code; OUTPUT: RETVAL
Re: AuthCookie questions
Christian Gilmore wrote: 4. I cannot modify the cookie and should not send additional cookies. [snip] about 4. Can I use an unmodified AuthCookie to ensure that whatever format the inbound cookie is in is sufficient and will not need to be modified or supplemented? I believe the answer is no, and, if it is, should this be What exactly do you mean by this? What are you trying to accomplish? Do you mean The user cannot modify the cookie? If thats what you mean, then yes, there are ways to do that. Basically you have to cryptographically sign the cookie using a secret that is unknown to the end user. There is an example of this in the Eagle book, and Apache::AuthTicket uses a scheme similar to this. Because you cant control what the cookie server sends, you'd probably have to do some sort of double redirect For example: o user is redirected to auth server o auth server returns cookie and redirects to /SIGNHANDLER o signhandler gets the cookie, cryptographically signs it, and returns the cookie to the client and redirects to real location o user is redirected to real location. If thats not what you mean, please elaborate. Regards, Mike
Re: protecting and entire site with AuthCookie and its derivatives?
George Valpak wrote: Is it possible to protect an entire site, from DocumentRoot, using AuthCookie? Yes. I've never done this myself personally, but people have reported success doing this. The trick is to configure apache so that your LOGIN handler is not inside the authentication realm. Since your wanting to protect the whole server, the trick is to use LocationMatch directives to specify that everything EXCEPT /LOGIN (or whatever your login handler is) gets protected. I dont have a configuration to post to you that will work because I've never done it, but its definitely possible becuase others have had success with it. Mike
Re: AuthCookie questions
Christian Gilmore wrote: 1. Read data from existing cookie. 1a. Redirect if cookie is non-existent. 2. Accept or reject cookie. 2a. If rejected, redirect. 2b. If accepted, populate environment and return. Sounds to me like you really dont need AuthCookie at all. You could just as easily do all of this by writing a PerlAccessHandler that does the above things. I'll second Perrin's comments. You definately have security problems with this. The only way to do this securely is to cryptograpically sign the cookie and to encrypt the data on the wire using SSL. Mike
Re: Apache::AuthCookie in mod_perl 1.99_5
Any comments? AuthCookie has not yet been ported to mod_perl 2.0. Mike
Attribute Handlers under mod_perl again
Hi everyone. I've revisited using Attribute::Handlers work under mod perl again, and I am still unsuccesful. Looking at Attribute::Handlers, it appears that Attribute::Handlers relies on CHECK blocks to do its work. I verified this by uncommenting one of the debugging warnings in Handlers.pm and compiling a module that uses Attribute::Profiled on the command line. When I do this I see: Handling Profiled on CODE(0x8a6cda0) in CHECK with [] But when running the module under mod_perl, the above warning never appears int he error log. accroding to this message: http://marc.theaimsgroup.com/?l=apache-modperlm=96639978528467w=2 mod_perl does not, and can not, support CHECK blocks at all, so this is sort of what I would expect. Given that, I'm curious how anyone has gotten Attribute::Handlers to work under mod_perl. Does anyone have any ideas? I'm running perl 5.6.1, mod_perl 1.27, apache 1.3.27, Attribute::Handlers 0.77. Mike
Re: Propogating Errors / E-Toys
Perrin Harkins wrote:
We've actually discussed this on the list. It has to do with closures.
Matt gave a presentation about exception handling which covers it and
shows a workaround. You can see it here:
http://axkit.org/docs/presentations/tpc2001/
Sorry to chime in a little late on this.
But the Exceptions slides from the page above are either misleading,
or I am misunderstainding just what exactly leaks in Error.
The slides above show a BAD example of Error.pm as:
sub handler {
my $r = shift;
my $count;
try {
# use $count in here...
} catch Error with {
};
}
However, the eToys article doesnt say that this is unsafe. What the
eToys article says is unsafe is code with nested try blocks like this:
my $count;
try {
...
try {
# use $count in *here*
};
};
in other words, if I understand the eToys article correctly, the leaks
only happen if I nest a try block inside another try block. I have
experimented some, and it appears to me that this is in fact the case
($count doesnt get cleaned up if there is a nested try). But as long as
I dont nest try blocks there doesnt appear to be a leak.
Are Matt's slides misleading on this point? Or am I missing something here?
Mike
Re: PerlSetVar WhatEverSecure
Brian Reichert wrote: Location /formscript/login PerlSetVar FormScriptSecure 1 AuthType Apache::AuthTicket ... /Location But, in each case, my login program is server in the clear. What am I missing? THe authnameSecure setting only affects the cookie. If you want to forbid access to the login form from non-ssl, there are verious ways to do that. One way would be to add SSLRequireSSL that block (assuming your using mod_ssl). Regards, Mike
Re: AuthCookie help
Jian Zhen wrote: Hi all, I have been scratching my head for a day now trying to figure out how to make AuthCookie work. I note that you have PerlSetVar WhatEverSecure 1 in your config. If that is the case, make sure you are accessing the from using HTTPS, not HTTP. This has been a common cause of this behaviour. With WhatEverSecure 1, the cookie will only be returned to the server on an SSL connection, but not a plain HTTP connection. I probably should document this better in the POD docs... Mike
Re: [RFC] Apache::AuthTicketPlus
Jim Helm wrote: Feel free to do whatever you want with the code... Comment/criticism welcome - especially on the init method. I'll post to CPAN if anyone thinks it's worth it. I'd gladly accept integrating this directly into AuthTicket if the maintainer wishes (Michael Schout?). I'm not crazy Yes, I think this is useful enough to fold this into AuthTicket. I'll take a closer look at it this weekend. Mike
Re: framesets/AuthCookie question
On Mon, 22 Apr 2002, Fran Fabrizio wrote: It seems that even if AuthCookie returns a FORBIDDEN with a custom_error page set, the $r-notes() don't propagate. Does apache consider the display of the custom_response page to be a completely new request? Its a subrequest, so the notes shold be in $r-prev-notes(). Mike
Re: framesets/AuthCookie question
On Wed, 17 Apr 2002, Peter Bi wrote: Fran: You may need to 1) add a few lines of code in AuthCookie to make your error code aware to other methods, and 2) have a dynamic login page that can interpret the code. Alternatively, you may try AccessCookie I posted. :-) The CVS version of AuthCookie has a custom_errors() hook in it that does this sort of thing. However, I dont think it will work for his problem because his javascript code seems to launch a NEW REQUEST, thus loosing anything that was stored away in $r-subprocess_env(). So the only viable option is to pass the error codes in they url (as part of the query string) I think. Mike
Re: Problem with Perl sections in httpd.conf, mod_perl 1.26
On 16 Apr 2002, PinkFreud wrote:
I have a rather odd problem, one which I can only assume is a bug
somewhere, due to how bizarre it is.
I am attmempting to generate virtual host configs via mod_perl, using
Perl sections in httpd.conf. Not all hosts will be using a /perl
Alias, though, so I'm reading in an external config, which looks like
the following:
This sounds like hte problem that I suffered with for about a year, until
someone posted this patch recently to the mod_perl list that fixes the problem
for me. For me, the symptom was that *sometimes*, certain entries in Perl
sections would not configure, no matter what was placed in them. The patch
below fixes it for me. Try the patch below and see if the problem goes away.
I'm not sure if this patch has made it into CVS yet or not.
Regards,
Mike
--
diff -ur mod_perl-1.26.orig/src/modules/perl/perl_config.c
mod_perl-1.26/src/modules/perl/perl_config.c
--- mod_perl-1.26.orig/src/modules/perl/perl_config.c Tue Jul 10 21:47:15 2001
+++ mod_perl-1.26/src/modules/perl/perl_config.cWed Feb 20 14:59:00 2002
-1166,6 +1166,7
char *tmpkey;
I32 tmpklen;
SV *tmpval;
+void *old_info = cmd-info;
(void)hv_iterinit(hv);
while ((tmpval = hv_iternextsv(hv, tmpkey, tmpklen))) {
char line[MAX_STRING_LEN];
-1195,6 +1196,7
if(errmsg)
log_printf(cmd-server, Perl: %s, errmsg);
}
+cmd-info = old_info;
/* Emulate the handling of end token for the section */
perl_set_config_vectors(cmd, cfg, core_module);
}
-1511,9 +1513,7
void *dummy = perl_set_config_vectors(cmd, config, core_module);
void *old_info = cmd-info;
-if (strstr(key, Match)) {
- cmd-info = (void*)key;
-}
+cmd-info = (void*)strstr(key,Match);
if(strnEQ(key, Location, 8))
perl_urlsection(cmd, dummy, hv);
--
Re: AuthCookie login ?
On Fri, 5 Apr 2002, Geoffrey Young wrote: Since the authentication happens on every trip into the server, and I don't want to run my code (to set up an Apache::Session for the user's session data) until I'm sure I have a valid user on my hands, I can't see a way to do the session setup only the first time after a sucessful login. can't you do this in authen_cred()? IIRC authen_cred is only called when no cookie is found, which means you have a first time visit (or an unsuccessful Yes, do it in authen_cred() after you have checked the credentials, but before returning the username. authen_cred() is only called when you submit the login form. Regards, Michael Schout (AuthCookie maintainer).
Attribute::Handlers - cant use under mod_perl?
I made an attempt to use Attribute::Handlers under mod perl today, and it
appears that this cant be done. What I was hoping to do was use
Attribute::Deprecated, and Attribute::Profiled in my perl handlers.That way
I could say something like:
package MyHandler;
sub whatever : Profiled { ... }
...
And I would get profile information written directly to the log file. Since
all of my handlers inherit from a common base class, I was thinking to
eventually create my own handler code that could be turned on or off by chaning
a configuration value eventually.
However, when running under mod_perl, the attribute handlers never get set up.
I think this is due to the fact that Attribute::Handlers uses CHECK and INIT
blocks to setup the handlers, and CHECK blocks dont get executed under
mod_perl.
Has anyone else tried to use Attribute::Handlers under mod_perl? Any success
stories?
Mike
Re: Perl Section Bug?
On 13 Feb 2002, Salvador Ortiz Garcia wrote: Ok, I found it. Right now all Location, Directory and Files are afected by being upgraded at random to the Match versions. Can you please test the following patch for perl_config.c: You might be intersted to know that this patch also fixes strange problems I was having with Perl sections as well. Here is a link to the email where I reported the bug: http://www.geocrawler.com/archives/3/182/2001/2/200/5185227/ Doug looked at it for a while, but nothing obvious jumped out at him either so it just got listed as a ToDo :). Applying the patch you sent in this tread to mod_perl 1.26 makes the problem go away. Mike
Re: Apache::AuthCookie not set cookie really
variable path=/agenda was omitted. Explorer 6.0 doesn't set cookie without path attribute. I think, it's a good idea to make WhatEverPath required option in config. Hrm. I was not aware of that. Thanks for bringing it to my attention. I have changed AuthCookie in CVS so that Path will be set to / unless the path has been configured. This will allow people who have configurations that dont specify the path to still use the new version without updating the config. Feel free to grab the source from CVS and try it out at: http://sourceforge.net/projects/ap-authcookie Mike
Re: Apache::AuthCookie not set cookie really
Location /agenda/ SetHandler perl-script PerlHandler Apache::Agenda PerlSetVar AgendaPath /agenda PerlSetVar AgendaTemplate default.inc PerlSetVar AgendaSessionDir /tmp PerlSetVar AgendaLoginScript /agenda/login/ Are you sure that last line is correct? That would send you to /agenda/login when authen_ses_key() fails, but your config below is for /LOGIN/. Location /LOGIN/ AuthType Apache::AuthCookieAgenda AuthName Agenda SetHandler perl-script PerlHandler Apache::AuthCookieAgenda-login /Location This implies to me that you meant to have: PerlSetVar AgendaLoginScript /LOGIN/ Is this just a typo? I used Apache::Session::Counted, and know that this two modules may conflict, but when all Apache::Session::Counted staff is commented result is the same... I dont think they conflict. I've not heard any reports of that anyway. The cookie names are unique so there should be no problem there. I dont know why cookie is not set. I'd suspect something isnt right with your configuration. Have you tried turning on warn me before accepting cookies on your browser? Sometimes that helps me verify that the cookies are actually making it to the browser. What your trying to do looks to me like exactly the sort of thing AuthCookie can do. Unless I am misunderstanding your problem I dont see an AuthCookie limitation here. Please explain in more detail if I am missing the point and I will see what we can do if such a limitation does in fact exist :). Regards, Michael Schout (Apache::AuthCookie maintainer)
Re: problems with Apache::AuthTicket
Tomasz Konefal wrote:
PerlSetVar FtpFuTicketSecretTable ticketsecrets:sec_version:sec_data
PerlSetVar FtpFuTicketExpires 15
PerlSetVar FtpFuTicketLogoutURI /authorized/ftpfu.cgi
PerlSetVar FtpFuTicketLoginHandler /ftpfulogin
PerlSetVar FtpFuTicketIdleTimeout 1
PerlSetVar FtpFuPath /
PerlSetVar FtpFuDomain .compt.com
PerlSetVar FtpFuSecure 1
PerlSetVar FtpFuLoginScript /ftpfuloginform
A few things that might cause this:
1) Did you remember to create a secret key in table ticketsecrets?
2) Are you accessing the forms using HTTPS (NOT HTTP)? You need to use
HTTPS if ${AuthName}Secure is true (which it is above).
3) Make sure FtpFuDomain matches the hostname you are accessing.
Everything else looks fine as far as I can tell.
Mike
Re: cleaning old Apache::Session's
On Fri, Jun 02, 2000 at 09:26:45AM +1000, Adam Cassar wrote: I was wondering how people are clearing out old Apache::Session's No timestamp is used on the fields used by Apache::Session, so how do we clear the old sessions? I am not talking about the delete() method to remove a session, as that presumes that a user will always leave your site via pre-defined access points. As was mentiuoned, TMTOWTDI, but for postgresql, you can just do: CREATE TABLE sessions ( id VARCHAR(32) NOT NULL, ts TIMESTAMP NOT NULL DEFAULT NOW(), a_session TEXT, PRIMARY KEY (id) ); Which works. Another equivalent solution would involve setting up a "view" on a different table abd setting up RULES that update the timestamp. E.g.: CREATE TABLE session_data ( id CHAR(32) NOT NULL, ts TIMESTAMP NOT NULL, a_session TEXT, PRIMARY KEY (id) ); CREATE VIEW sessions AS SELECT id,a_session FROM session_data; CREATE RULE sessions_update AS ON UPDATE TO sessions DO INSTEAD UPDATE session_data SET id = NEW.id, a_session = NEW.a_session, ts = CURRENT_TIMESTAMP WHERE id = OLD.id; CREATE RULE sessions_delete AS ON DELETE TO sessions DO INSTEAD DELETE FROM session_data WHERE id = OLD.id; CREATE RULE sessions_insert AS ON INSERT TO sessions DO INSTEAD INSERT INTO session_data (id, a_session, ts) VALUES (NEW.id, NEW.a_session, CURRENT_TIMESTAMP); This works too. And has the added nifty feature that "sessions" looks exactly like what Apache::Session expects to find. I'm sure there are other ways to do it (plpgsql, triggers come to mind) for postgresql. As I said, TMTOWTDI. I'm sure nearly every dbms out there can use some variant of one of the above two methods... You'll just have to adapt it for your particular DBMS. Mike
Re: [ANNOUNCE] Apache::Session 1.51
On Fri, May 26, 2000 at 03:35:51PM -0700, Jeffrey W. Baker wrote:
Greetings,
I have released Apache::Session 1.51. The addition of the Oracle backing
store took less time than expected. It is included and tested in this
release. This is the only change from 1.50.
I just took a look at 1.51 (was using 1.08 before).
There seems to be a bug with Apache::Session::Store::Postgres
The pod docs suggest that this is legal:
tie %session, 'Apache::Session::Postgres', $id, {
Handle = $dbh,
Commit = 1
};
However, if Handle is present, the Commit arg is ignored. In
Apache::Session::Store::Postgres:
if (exists $session-{args}-{Handle}) {
$self-{dbh} = $session-{args}-{Handle};
return;
}
That should also set $self-{commit} = $session-{args}-{Commit} before
returning, no?
Mike
Re: Apache::Session::Pg blob support?
On Fri, May 26, 2000 at 12:25:39PM -0700, Jeffrey W. Baker wrote: Yes it would be great to break the 8K (actually slightly less) limit, if it doesn't hamper performance too much. I read the docs on the Postgres web site, but I didn't find anything interesting about blob support. I'm working on such a package. I will send it to you when I have it working to my liking :). Mike
Re: ANNOUNCE: Apache-TicketAccess 0.10
On Tue, Apr 25, 2000 at 11:55:26AM -0700, Doug MacEachern wrote: On Sat, 22 Apr 2000, Michael Schout wrote: I dont know what else I would name it. It is extremely similar to the TicketAccess system in the eagle book, with a lot of extra features added in. please come up with a different name, it's way too confusing for two different modules to have the same name. Okay. I guess I am at a loss as to what this module should be named then. It is heaily based on the TicketAccess system in the modperl book. It is a ticket based authentication system. Maybe Apache::AuthTicket? Does anyone have any suggestions? Mike
Re: Implementing security in CGI
On Thu, Apr 20, 2000 at 12:15:16PM -0400, DeWitt Clinton wrote: The secure session has the following properties: *) The user is able to initiate a secure session by providing proper credentials (i.e., a username and password pair) via a login process. *) The user is able to terminate the secure session via a logout process. *) Secure sessions must be able to time out automatically. *) Secure sessions must *never* transmit sensitive data (such as the password) over insecure channels. my Apache::TicketAccess module does all of this, but it uses Cookies for the transport mechanism. So if using cookies are okay, them Apache::TicketAccess may be a solution for some folks. Mike
Re: ANNOUNCE: Apache-TicketAccess 0.10
On Thu, Apr 20, 2000 at 02:16:09PM -0700, Doug MacEachern wrote: On Tue, 18 Apr 2000, Michael J Schout wrote: Apache-TicketAccess-0.10.tar.gz cool, but, there's already a module named Apache::TicketAccess, listed in the apache-modlist.html: TicketAccess bdpOTicket based access/authentication MPB Does this entry in the apache-modlist exist anywhere? I looked for it on CPAN, but I cant even find MPB's directory on CPAN. If the module is no longer in existance, then maybe my module can replace it? I dont know what else I would name it. It is extremely similar to the TicketAccess system in the eagle book, with a lot of extra features added in. Mike
Re: Embperl segfaulting under perl 5.6.0
Doh!
I just checked the development version of HTML::Embperl, and this is fixed in
there.
Gerald: Could we patch this fix in to the HTML::Embperl stable tree and get a
new stable release? I would like to avoid running the beta version of Embperl
on a production site :).
The patch in question I would like to see in the stable release includes
differences between revision 1.24 and 1.26:
diff -c -r1.24 -r1.26
*** Embperl.xs 2000/01/04 06:10:02 1.24
--- Embperl.xs 2000/03/28 19:46:04 1.26
***
*** 71,78
SV * gv
CODE:
RETVAL = "" ;
! if (gv SvTYPE(gv) == SVt_PVGV)
{
GV * fgv = GvFILEGV(gv) ;
if (fgv SvTYPE(fgv) == SVt_PVGV)
{
--- 71,86
SV * gv
CODE:
RETVAL = "" ;
! #ifdef GvFILE
! if (gv SvTYPE(gv) == SVt_PVGV GvGP (gv))
{
+ char * name = GvFILE (gv) ;
+ if (name)
+ RETVAL = name ;
+ }
+ #else
+ if (gv SvTYPE(gv) == SVt_PVGV GvGP (gv))
+ {
GV * fgv = GvFILEGV(gv) ;
if (fgv SvTYPE(fgv) == SVt_PVGV)
{
***
*** 81,86
--- 89,95
RETVAL = name ;
}
}
+ #endif
OUTPUT:
RETVAL
Mike
[JOBS] Global Knowledge Group Inc.
Hi! Here is a job posting from the company I work for. If anyone here has any general questions, you can just email me, otherwise, you can apply by sending your information in to Global Knowledge Group as described at the end of the posting. Mike - We are looking for several mod_perl application developers immediately. Who we're looking for: We're in the market for an Application developer with detailed knowledge of web server / web development on Unix systems. You should have 2+ years experience in software development using C/C++, perl/CGI, with a very high level of understanding of Apache web server and mod_perl. mod_perl experience on a unix system is the primary requirement. Applicants should be also be familiar with SQL and DBI. Should be able to develop high traffic web applications and be able to tune the server/apps for system performance. Needs to integrate into existing team. Communication skills a must! Who we are: Since the monopoly of Network Solutions, Inc has been broken up, Global Knowledge Group has been accredited to be a TLD registrar for the .com, .net, and .org domains. We are pre IPO and growing fast. We are committed to our employees and to our customers and our actions always take these 2 into consideration. Our office environment is very relaxed and we like to have fun while we get our work done. We are growing very fast and we project about 160 new employees will be needed before the end of this year. We have a virtual officing concept that allows our employees to have home based offices and work remotely. Our management team has 75+ years experience in the hi tech industry and extensive years in the commercial banking industry as well. Please send your resume by email, fax or ground mail to: Global Knowledge Group 7607 Eastmark Dr, Suite 202 College Station, TX 77840 Fax: (409) 694-7060 Email: [EMAIL PROTECTED] If possible, please include a list of mod_perl projects you have worked on as references. Feel free to call me at (800) 617 0412 or email me if you have any questions. Taylor Marvin
Re: ANNOUNCE: Apache::Filter 1.06
Ken Williams wrote:
Changes:
- Added 'handle' parameter to filter_input(), which lets callers open the
input filehandle themselves.
[[EMAIL PROTECTED] (Vegard Vesterheim)]
Hi Ken.
I've figured out that using this, I can *cheat* and get Apache::Filter
to
work with my handler whereas I could not get it to work before. Let me
explain.
I've got a PerlHandler called "MJS::AppServer" which was configured as:
Location /myapps/
SetHandler perl-script
PerlHandler MJS::AppServer
/Location
Basically what this handler does is accept a URI like:
/myapps/CreateUser
and the handler sees that "CreateUser" is in the path info. Because of
this,
it does "my $app = MJS::Applications::CreateUser-new($r);
$app-service();"
(well it does more, but that is the basic thing it does).
Anyway, when using previous versions of Apache::Filter with this
handler, I
would get "NOT_FOUND" returned because of course, Apache::Filter cant
open
/myapps/CreateUser.. it just plain does not exist... Neither does the
directory /myapps.
But, using this version, in AppServer.pm, I am able to do:
if (lc $r-dir_config('Filter') eq 'on') {
$r-filter_input(handle=1);
}
And everything is fine from then out (I usually pass it through
Apache::SSI).
So now we use it like:
PerlHandler MJS::AppServer Apache::SSI
And it all works.
Maybe you could consider making a dir_config() directive to
get this behaviour? Something like "Filter_No_Input On" to say
that there is no input for the first handler and the first handler
provides the output itself? That way I dont have to resort to
abusing the "handle" argument to get the desired behavior :)
Or is there a different way to do this that I am missing?
Thanks.
Mike Schout
cant call bytes_sent.. solved!
Okay. I solved my problems with CGI::Carp complaining and httpd not starting. I had neglected to install a few extra modules on the second machine that I needed, and startup.pl was bailing out. Consequently, CGI::Carp had been pulled in, so that tries to run fatalsToBrowser.. But since its just in server init, and not really a request, CGI::Carp breaks. Anyways, installing the extra module I needed (which was a 3rd party module), fixed it for me. Regards, Mike
