Apache::AuthCookie 3.05 prerelease

2003-08-01 Thread Michael Schout
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

2003-06-11 Thread Michael Schout
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

2002-11-07 Thread Michael Schout
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...

2002-11-07 Thread Michael Schout
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

2002-11-06 Thread Michael Schout
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?

2002-11-04 Thread Michael Schout
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?

2002-11-02 Thread Michael Schout
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

2002-10-25 Thread Michael Schout
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

2002-10-25 Thread Michael Schout
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

2002-10-22 Thread Michael Schout
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?

2002-10-22 Thread Michael Schout
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

2002-10-22 Thread Michael Schout
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

2002-10-21 Thread Michael Schout
Any comments?


AuthCookie has not yet been ported to mod_perl 2.0.

Mike




Attribute Handlers under mod_perl again

2002-07-24 Thread Michael Schout

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

2002-07-09 Thread Michael Schout

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

2002-06-13 Thread Michael Schout

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

2002-05-15 Thread Michael Schout

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

2002-05-15 Thread Michael Schout

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

2002-04-23 Thread Michael Schout

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

2002-04-19 Thread Michael Schout

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

2002-04-16 Thread Michael Schout

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 ?

2002-04-09 Thread Michael Schout

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?

2002-03-29 Thread Michael Schout

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?

2002-02-20 Thread Michael Schout

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

2002-01-30 Thread Michael Schout

 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

2002-01-29 Thread Michael Schout


 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

2002-01-08 Thread Michael Schout

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

2000-06-01 Thread Michael Schout

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

2000-05-30 Thread Michael Schout

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?

2000-05-26 Thread Michael Schout

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

2000-04-26 Thread Michael Schout

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

2000-04-22 Thread Michael Schout

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

2000-04-22 Thread Michael Schout

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

2000-03-30 Thread Michael schout

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.

2000-02-04 Thread Michael schout

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

2000-02-02 Thread Michael schout

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!

2000-01-25 Thread Michael schout

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