Best way?

[Scott Alexander]

Hi,

I have in every script

my $user_language = library::language($user, $dbh) ; 
# is it finnish, english or swedish
my %output = library::load_language($user_language) ; 
# ties %output to a dbm

%output holds all the different outputs needed for each language

then for my subs which are in a package library I pass a reference

library::menu($db, \%output) ; #passes a reference to sub menu

%output never gets modified only read. 

I am using mod_perl. Is this the most efficient way of doing things?

I discovered the mistake I had when I turned on use strict in my library 
package. Before this I didn't pass %output to each sub ... to be honest I really

didn't understand how each sub new the values in %output. After turning on use 
strict I had to pass \%output because %output was empty in the subs.

hope this makes sense.

Scott


Scott Alexander tietoverkkosuunnittelija
[EMAIL PROTECTED]
gsm: +358 (0)40 7505640

Re: speed up/load balancing of session-based sites

[Mark Imbriaco]

On 10 May 2000, Stephen Zander wrote:

> > "Perrin" == Perrin Harkins <[EMAIL PROTECTED]> writes:
> Perrin> I think every RDBMS I've seen, includig MySQL, guarantees
> Perrin> atomicity at this level.
> 
> Look, Mummy, the funny man said MySQL and RDBMS in the same sentence :)

Please don't start on this.  I'm really sick of hearing Phil Greenspun
harp on the evils of MySQL, and I don't think this is the place to relive
that discussion all over again.  Yes, I see the smiley, but this topic is
so inflammatory that I felt a response in an attempt to prematurely stop
the insanity was in order. :-)  All databases suck.  Pick the one that
sucks the least for what you're trying to accomplish and move on.

-Mark

Re: speed up/load balancing of session-based sites

[Stephen Zander]

> "Perrin" == Perrin Harkins <[EMAIL PROTECTED]> writes:
Perrin> I think every RDBMS I've seen, includig MySQL, guarantees
Perrin> atomicity at this level.

Look, Mummy, the funny man said MySQL and RDBMS in the same sentence :)

-- 
Stephen

"There are those who call me... Tim"

Re: [Summation] 100% sessions?

[Gunther Birznieks]

At 01:21 PM 5/10/00 -0500, Jay Jacobs wrote:
>I embedded notes into this with a short book at the end...
>
>On Wed, 10 May 2000, Gunther Birznieks wrote:
>
> > There is a strong reason for cookies only. Intranets and other controlled
> > environments.
>
>
>I'm trying to satisfy as many clents as possible in the chaos of the
>uncontrolled world of a public site.

I was under the impression that this thread is about general session 
architectures... and someone appeared to be arguing that there are no 
situations where cookies alone would not cut it. The reality is that there 
are quite a few developers who develop using cookies alone and accept it as 
their user constraint. In an intranet with controlled users where the 
business wants an app out quickly, they don't care about the flexibility 
for the future especially if the apps are re-engineered to new business 
requirements every 6 months anyway.

> > >User makes request:
> > >   if a cookie exists with session_id
> > > then verify it is a valid session_id
> > > if a session-url exists remove it and rely on cookies
> >
> > Why would both exist?
>
>Becuase they're both set on an initial request, that way if the cookie
>fails, the session is still in the url... again, uncontrolled, sloppy
>world.
>
> > > if session is expired   # timed expirations as a security measure
> > >   auth them again if needed and/else redirect to requested page.
> > >
> > >   else if a session_url exists with no cookie
> > > verify validity and exipiration as above
> > >
> > >   else if no cookie and no url session
> > > new session, set cookie and set session-url
> > >
> > >   timestamp the session for expiration.
> > >
> > >
> > >Other notes:
> > >   Having to re-write site-wide urls seems like a bad idea.  It 
> negates any
> > >caching (on both server and client sides), and forces all the pages to be
> > >dynamic.  Relative links (although not the ../../prettiest thing) seems
> > >like the best route.
> >
> > I don't get this. It's still a different URL whether the id is at the end
> > of the URL or the beginning. Also, the pages are not dynamic with
> > mod_rewrite... mod_rewrite (in this case) is just acting upon a data
> > structure on the server.  The HTML files are still served as HTML files
> > whether the root dir is shown as a session id
> >
> > The caching that you are ruining is the proxy caching. But the browsers
> > will still cache the HTML and images (one would presume that multimedia
> > content -- which benefits the most from a proxy cache would not go through
> > the URL mangling if possible).
>
>
>The thing about putting the session_id in the front is that the whole site
>can then just do *static* relative linking.  The problem isn't using
>mod_rewrite to get to the page, the problem is linking from that page to
>another while maintaining the session_id in the url.  If I'm understanding
>you wrong let me know, I'd be quite interested in a solution just using
>mod_rewrite.
Of course, if you put the session id at the front of the URL, then the 
relative links will all work (unless they are absolute with regards to the 
host).

However, it should be relatively easy to make this a lot cleaner in 
conjunction with mod_rewrite... You have the URL (seen below) as 
/abcdef123456abcdef/index.html

But there is no primer... If we change the URL to

/sessionid/abcdef123456abcdef/index.html

Then you can create a mod_rewrite rule that checks for /sessionid/(.*)endid/.*

And then takes the equivalent of $1 and pushes it into an environment 
variable (lets call it $ENV{SESSIONID}).

Then have mod_rewrite strip the sessionid crap out of the URL and pass the 
rest to the server as the TRUE url.

Then even CGI scripts (not just mod_perl ones) can take advantage of using 
the $ENV{SESSIONID} to see if a sessionid was stripped out.

I'll talk about another advantage down below:

>And with caching... Let's say the site rewrites the url dynamically, so
>that the links are something like:
>Home page
>Now, for whatever unforseen reason the session_id changes (they close
>their account and reopen). They hit a page that is cached on their side
>with these in there, all of sudden they're back on their old session which
>is invalid now.  That doesn't exist if the link is "../index.html" or some
>other relative link that is cached.
>
>In addition I was also talking about server-side caching, with something
>like mason where it's possible to cache a static document on the server
>side to speed up the process.  Think of an "about" page talking about the
>company history... the session will have to be active there, they may want
>to look at their account info after that, but the about page is static and
>should be cached if possible.

OK. But if you use mod_rewrite to catch the URL before it has been 
processed by the content-handler, then the URLs will all appear without the 
session id to mason or something else that is caching the static pages.

Therefore the 

[OT] Re: growing processes

[Stephen Zander]

> "Wim" == Wim Kerkhoff <[EMAIL PROTECTED]> writes:
Wim> We're using SqlNet to connect multiple Linux web servers to
Wim> Oracle running on a Solaris box.

Adjust 'processes' and 'sessions' upwards in your init.ora file
on your database server.

Use:

svrmgrl
connect inernal
show paramete 

to see what's currently being used.

-- 
Stephen

"And what do we burn apart from witches?"... "More witches!"

Re: Need help on "Error on evaluating script from P-code"

[___cliff rayman___]

i always send ascii.
i was responding to an e-mail sent in html format.

amy,
you got me in trouble :-)

--
___cliff [EMAIL PROTECTED]
David McCabe wrote:

> > From: ___cliff rayman___ <[EMAIL PROTECTED]>
> > Date: Wed, 10 May 2000 14:40:14 -0700
> > Subject: Re: Need help on "Error on evaluating script from P-code"
> >
> > 
> > 
>
> Do us all a favor and change your Netscape Messenger settings to send ascii mail and 
>not
> HTML mail, please.
>
> David McCabe  Unix System Administrator
> Le Groupe Videotron [EMAIL PROTECTED]   (514) 380 4433
>
> I live in Quebec, ...
> Where the legal drinking age is just a suggestion
>  From "IamnotCanadian"

Re: Need help on "Error on evaluating script from P-code"

[David McCabe]

> From: ___cliff rayman___ <[EMAIL PROTECTED]>
> Date: Wed, 10 May 2000 14:40:14 -0700
> Subject: Re: Need help on "Error on evaluating script from P-code"
> 
> 
> 

Do us all a favor and change your Netscape Messenger settings to send ascii mail and 
not
HTML mail, please.



David McCabe  Unix System Administrator
Le Groupe Videotron [EMAIL PROTECTED]   (514) 380 4433

I live in Quebec, ...
Where the legal drinking age is just a suggestion
 From "IamnotCanadian" 

Re: Need help on "Error on evaluating script from P-code"

[Ask Bjoern Hansen]

On Wed, 10 May 2000, amy wrote:

> Running Apache 1.3.12, mod_perl 1.23, ePerl 2.2.13, mysql 3.23.14a

Try testing your index.iphtml outside the mod_perl environment. Maybe DBI
can't connect to the database server for some reason?

It's a long time since I've worked with ePerl, but I believe that there is
some command line tools for that included in the package. 


 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

Re: Need help on "Error on evaluating script from P-code"

[___cliff rayman___]

 
amy wrote:
 
PerlModule Apache::ePerl

    Options +ExecCGI
    SetHandler perl-script
    PerlHandler Apache::ePerl

I don't think an asterik is allowed here.
you need to  use:

or

or easier

--
___cliff [EMAIL PROTECTED]
 

Need help on "Error on evaluating script from P-code"

[amy]

Running Apache 1.3.12, mod_perl 1.23, ePerl
2.2.13, mysql 3.23.14a
get error message in apache/logs :
[error] access to /usr/local/bin/apache/http/index.iphtml
failed for
127.0.0.1, reason: Apache::ePerl: Error
on evaluating script from
P-code
apache/conf/httpd.conf :
DocumentRoot "/usr/local/bin/apache/http"

    Options Indexes FollowSymLinks
ExecCGI
    AllowOverride None
    Order allow,deny
    Allow from all

Perlrequire /usr/local/bin/apache/http/startup.perl
PerlModule Apache::ePerl

    Options +ExecCGI
    SetHandler perl-script
    PerlHandler Apache::ePerl


    Options +ExecCGI
    SetHandler perl-script
    PerlHandler Apache::Status

apache/http/startup.perl :
#!/usr/local/bin/perl5
use strict;
use Apache::Registry;
use DBI();
use Carp();
$SIG{__WARN__} = \&Carp::cluck;
use CGI;
CGI->compile(':all');
1;
apache/http/index.iphtml :

   
use DBI;
   
my $data_source = "DBI:mysql:testdb";
   
my $username = "test";
   
my $password = "test";
 
   
my $db_handle = DBI->connect( $data_source, $username, $password ) or
   
die $DBI::errstr;
!>//

   
  Testing  



 
 
Any idea what I did wrong, commands, suggestions,
please help.
Thank you.
 

Re: mod_perl on Cobalt servers?

[Andrew Wyllie]

Hi Bakki,


I have used mod_perl on a Cobalt Qube.  It ran ok, but I would recommend
getting a lot of memory for it.  The problems I ran into were mostly
related to the Qube not being that great of a development environment.
The Qube is great as a firewall/internet server for a small compnay, but
if you need to run 200 Virtual domains, I would recommend buying some
higher end hardware and learning how to administer it yourself.
For example, the RAQ3 has a AMD K6 200 (equiv to a pentium 200?) and
costs $1500 for a 64MB and smallish harddrive.  For $2300, I put
together a dual PIII 600 machine with 512MB RAM and 20GB disk all in a
2U case.  Shove on FreeBSD or whatever and you have a pretty sweet box.


andrew



On Wed, 10 May 2000, Bakki Kudva wrote:

> I would like to hear from anyone who has had some experience with
> mod_perl on Cobalt's Qube2(MIPS RISC) or Raq3 (x86) microservers.
> 
> * How well does this work?
> * Any differences between the Qube & Raq relative to mod_perl?
> * Any caveats?
> * How well does it work for virtual domains?
> * Does it void warranty?
> 
> The Raq3 is supposed to support 200 virtual domains but I am sure it is
> without mod_perl compiled in. What is a practical number of virt domains
> with mod_perl which can be run on this box? I have seen some blurbs
> about unsupported software (ie. anything not shipped with the box)
> voiding Cobalt warranty. Has anyone experienced problems with support
> from Cobalt on mod_perl enabled Qubes?
> 
> Thanks in advance,
> 
> bakki
> -- 
>   _ _
>  .-. |M|S|Bakki Kudva
>  |D|_|a|y|Navaco
>  |o|m|n|s|<\  420 Pasadena Drive
>  |c|e|a|t| \\ Erie, PA 16505-1037
>  |u|n|g|e|  \\http://www.navaco.com/
>  | |T|e|m|   \>   ph: 814-833-2592
> ""fax:603-947-5747
> e-Docs

...
Andrew  Wyllie   <[EMAIL PROTECTED]>Open Source Integrator
v.206.729.7439  __We can catify or stringify,
c.206.851.9876separately or together!__ perl-5.005_03

Re: Source Code Shows Up in IE But Not Netscape

[Billy Donahue]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 10 May 2000, Bri Carey wrote:

> Date: Wed, 10 May 2000 05:26:52 PDT
> From: Bri Carey <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Source Code Shows Up in IE But Not Netscape
> 
> I realize that this is not an ePerl forum, but since ePerl runs as part of 
> mod_perl, I thought it couldn't hurt to at least ask here.
> 
> I must be missing something obvious.
> 
> I've installed Apache::ePerl.
> 
> I've configured httpd.conf according to the instructions:
> 
> 
> Options +ExecCGI
> SetHandler perl-script
> PerlHandler Apache::ePerl
> 
> 
> When I display an .iphtml page in Netscape, everything seems to be fine.
> 
> When I display it in IE (4.72), I get a plain text output of the source
> code, including html tags.
> 
> Why this discrepancy?

IE quite brilliantly ignores the MIME type specified in the header
in some cases... If you send IE a Content-Type: text/plain 
document that happens to begin with  then it will render it
as HTML... This sounds like a related problem, but with the opposite effect:
that is to say, it's now NOT rendering when it should be.

- --
"The Funk, the whole Funk, and nothing but the Funk."
Billy Donahue 
http://dadadada.net
GnuPG Key ID: 0219745D Billy Donahue <[EMAIL PROTECTED]>
Fingerprint: 869A 2453 36F4 09BA 1D83  1839 FB65 6FA7 0219 745D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Made with pgp4pine 1.75

iD8DBQE5GVbJ+2VvpwIZdF0RAoLwAJ9zTrqLcTI5RxC3jyA37r5EuCm4xgCggvKY
GJ56MsQ704UE6F1E31fzaYo=
=zfpG
-END PGP SIGNATURE-

mod_perl on Cobalt servers?

[Bakki Kudva]

I would like to hear from anyone who has had some experience with
mod_perl on Cobalt's Qube2(MIPS RISC) or Raq3 (x86) microservers.

* How well does this work?
* Any differences between the Qube & Raq relative to mod_perl?
* Any caveats?
* How well does it work for virtual domains?
* Does it void warranty?

The Raq3 is supposed to support 200 virtual domains but I am sure it is
without mod_perl compiled in. What is a practical number of virt domains
with mod_perl which can be run on this box? I have seen some blurbs
about unsupported software (ie. anything not shipped with the box)
voiding Cobalt warranty. Has anyone experienced problems with support
from Cobalt on mod_perl enabled Qubes?

Thanks in advance,

bakki
-- 
  _ _
 .-. |M|S|  Bakki Kudva
 |D|_|a|y|  Navaco
 |o|m|n|s|<\420 Pasadena Drive
 |c|e|a|t| \\   Erie, PA 16505-1037
 |u|n|g|e|  \\  http://www.navaco.com/
 | |T|e|m|   \> ph: 814-833-2592
""  fax:603-947-5747
e-Docs

Re: [Summation] 100% sessions?

[Jay Jacobs]

I embedded notes into this with a short book at the end...

On Wed, 10 May 2000, Gunther Birznieks wrote:

> There is a strong reason for cookies only. Intranets and other controlled 
> environments.


I'm trying to satisfy as many clents as possible in the chaos of the
uncontrolled world of a public site.

> >User makes request:
> >   if a cookie exists with session_id
> > then verify it is a valid session_id
> > if a session-url exists remove it and rely on cookies
> 
> Why would both exist?

Becuase they're both set on an initial request, that way if the cookie
fails, the session is still in the url... again, uncontrolled, sloppy
world.

> > if session is expired   # timed expirations as a security measure
> >   auth them again if needed and/else redirect to requested page.
> >
> >   else if a session_url exists with no cookie
> > verify validity and exipiration as above
> >
> >   else if no cookie and no url session
> > new session, set cookie and set session-url
> >
> >   timestamp the session for expiration.
> >
> >
> >Other notes:
> >   Having to re-write site-wide urls seems like a bad idea.  It negates any
> >caching (on both server and client sides), and forces all the pages to be
> >dynamic.  Relative links (although not the ../../prettiest thing) seems
> >like the best route.
> 
> I don't get this. It's still a different URL whether the id is at the end 
> of the URL or the beginning. Also, the pages are not dynamic with 
> mod_rewrite... mod_rewrite (in this case) is just acting upon a data 
> structure on the server.  The HTML files are still served as HTML files 
> whether the root dir is shown as a session id
> 
> The caching that you are ruining is the proxy caching. But the browsers 
> will still cache the HTML and images (one would presume that multimedia 
> content -- which benefits the most from a proxy cache would not go through 
> the URL mangling if possible).


The thing about putting the session_id in the front is that the whole site
can then just do *static* relative linking.  The problem isn't using
mod_rewrite to get to the page, the problem is linking from that page to
another while maintaining the session_id in the url.  If I'm understanding
you wrong let me know, I'd be quite interested in a solution just using
mod_rewrite.

And with caching... Let's say the site rewrites the url dynamically, so
that the links are something like:
Home page
Now, for whatever unforseen reason the session_id changes (they close
their account and reopen). They hit a page that is cached on their side
with these in there, all of sudden they're back on their old session which
is invalid now.  That doesn't exist if the link is "../index.html" or some
other relative link that is cached.

In addition I was also talking about server-side caching, with something
like mason where it's possible to cache a static document on the server
side to speed up the process.  Think of an "about" page talking about the
company history... the session will have to be active there, they may want
to look at their account info after that, but the about page is static and
should be cached if possible.

Again, I'm just trying to get a feel for the best way to deal with the
chaos of the browsers and their users.  I don't see any way to gaurantee
that 100% of the people will be able to use a session-based site while
also allowing 0 session-jumping with high-security and privacy.  And if I
can increase 91% serviced to 92% serviced while assuming the end-user just
figured out what "click here" means, I'll do it.

Jay Jacobs
LachNet Inc.

Re: [Summation] 100% sessions?

[Gunther Birznieks]

There is a strong reason for cookies only. Intranets and other controlled 
environments.

You generally do not have to worry about the lack of cookies, and if a user 
does have them turned off in the organization, then you can mandate them to 
turn them on as corporate policy if they want to use the app.

I've seen many large organizations do this without nary a cry from the 
users.  And it speeds up development tremendously if you don't have to 
think about URL mangling stuff. I have to say that I do like the 
mod_rewrite with session id stripped from the front of the URLs a lot.

Later,
Gunther

PS Minor comments within the message...

At 11:36 AM 5/10/00 -0500, Jay Jacobs wrote:
>On Wed, 10 May 2000, Roger Espel Llima wrote:
>
> > Jay Jacobs <[EMAIL PROTECTED]> wrote:
> > >   So as I see it there are essentially 2 *mostly* reliable ways, cookies
> > > and url-rewriting.  Both have drawbacks and neither are 100%.  There
> > > really isn't a way to cross-reference anything else (IP or login) becuase
> > > there are valid reasons for a user to come from multiple ip addresses
> > > during a session (albeit rare), and sessions may be needed without
> > > requiring a user to login.
> >
> > >   It also doesn't make sense to try to rely on both cookies and
> > > url-rewriting, that would just get sloppy and waste time.  The only thing
> > > to do is to pick one or the other and deal with the drawbacks associated
> > > with that...
> >
> > Why wouldn't it make sense?  Some users have cookies turned off, then
> > you just send them a rewritten URL.  That's what I do now: send a
> > session cookie with every request.  If I got a session cookie from the
> > client, then that's it; if not, I also add the session data at the end
> > of the internal links.
>
>After sleeping on it I agree to a point.  I think the url-session should
>be first thing in the url and the site should be fully relatively linked.
>Cookies are a lot "cleaner" for the user and transparent.  So I've written
>up pseudo-code (I learned something in college!) on the logic:
>
>User makes request:
>   if a cookie exists with session_id
> then verify it is a valid session_id
> if a session-url exists remove it and rely on cookies

Why would both exist?

> if session is expired   # timed expirations as a security measure
>   auth them again if needed and/else redirect to requested page.
>
>   else if a session_url exists with no cookie
> verify validity and exipiration as above
>
>   else if no cookie and no url session
> new session, set cookie and set session-url
>
>   timestamp the session for expiration.
>
>
>Other notes:
>   Having to re-write site-wide urls seems like a bad idea.  It negates any
>caching (on both server and client sides), and forces all the pages to be
>dynamic.  Relative links (although not the ../../prettiest thing) seems
>like the best route.

I don't get this. It's still a different URL whether the id is at the end 
of the URL or the beginning. Also, the pages are not dynamic with 
mod_rewrite... mod_rewrite (in this case) is just acting upon a data 
structure on the server.  The HTML files are still served as HTML files 
whether the root dir is shown as a session id

The caching that you are ruining is the proxy caching. But the browsers 
will still cache the HTML and images (one would presume that multimedia 
content -- which benefits the most from a proxy cache would not go through 
the URL mangling if possible).

>This way of doing sessions doesn't sit right with me, but I suppose when
>your only tool is a hammer...
>
>Jay Jacobs
>LachNet Inc.

Re: Using -w in a package

[___cliff rayman___]

I believe perl 5.6.0 has a new pragma:

use warnings;

this can be used inside modules and will turn on
warnings for that module only.  See the new docs
for details.

--
___cliff [EMAIL PROTECTED]

Scott Alexander wrote:

> Hi,
>
> I've used #!/usr/bin/perl -w in all of my scripts
>
> but how can I use -w in a package ?
>
> I have always declared variables with my in a sub but speling mistakes will
> happen. And I don't get any warnings. How can I do this?
>
> regards and thanks in advance
>
> Scott
>
> 
> Scott Alexander tietoverkkosuunnittelija
> [EMAIL PROTECTED]
> gsm: +358 (0)40 7505640

Re: Source Code Shows Up in IE But Not Netscape

[___cliff rayman___]

I don't think you are using the Files directive properly.
It seems to have some Directory information as well as Files information.

Try something like this:


  
SetHandler  perl-script
PerlHandler Apache::ePerl
Options +ExecCGI
  


Bri Carey wrote:

> > > When I display an .iphtml page in Netscape, everything seems to be fine.
> > >
> > > When I display it in IE (4.72), I get a plain text output of the source
> > > code, including html tags.
> > >
> > > Why this discrepancy?
> >
> >IE quite brilliantly ignores the MIME type specified in the header
> >in some cases... If you send IE a Content-Type: text/plain
> >document that happens to begin with  then it will render it
> >as HTML... This sounds like a related problem, but with the opposite
> >effect:
> >that is to say, it's now NOT rendering when it should be.
>
> I've tried setting the default type to text/html in the httpd.conf file and
> that didn't seem to do the trick.
>
> I appreciate the input that I've received.
>
> I've also noticed that both browsers display the code, although they format
> the html properly, when I try to execute the script inside of a standard
> .html document.  I know that's not the standard (embedded Perl should have
> .iphtml extensions - at least that's the way it seems to be).  Yes, I have
> made the appropriate changes in the httpd.conf file:
>
> PerlModule Apache::ePerl
>
>Options +ExecCGI
>SetHandler  perl-script
>PerlHandler Apache::ePerl
>
>
> You can see this now at http://www.uncricket.com/index1.html
>
> Thanks again for any input.
>
> Regards,
> Bri
> 
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

--
___cliff [EMAIL PROTECTED]

ch6.html missing single quote

[Tim DiLauro]

On Wed, 10 May 2000, Matt Sergeant wrote:

> On Wed, 10 May 2000, Niral Trivedi wrote:
> 
> > All,
> > 
> > I am not sure whether this is the right place to ask this question...
> > sorry if not..
> > 
> > My question is, Can we use custom database for authentication with
> > Apache instead of default text based authentication???
> > 
> > Has anybody done that before?? I have looked apache site and cpan site..
> > but couldn't find any documentation...
> > 
> > Can  somebody give me some idea please??
> >
> 
> I can do better than give you some advice!
> 
> http://www.modperl.com/book/chapters/ch6.html
> 
> 

There is a missing terminal single quote in the section discussing Basic
authentication.  The section looks like this.

   % perl -MMIME::Base64 -le 'print decode_base64 "Z2FuZGFsZjp0aGUtd2l6YXJk"
   gandalf:the-wizard

Single quote is missing from the end of the line.

-timmo


-- 
---
Tim DiLauro  Milton S. Eisenhower Library
Digital Knowledge Center Johns Hopkins University
(410) 516-5263   3400 N. Charles Street
[EMAIL PROTECTED]Baltimore, MD  21218
---

Re: may be an offtopic question..

[Vivek Khera]

> "NT" == Niral Trivedi <[EMAIL PROTECTED]> writes:

NT> My question is, Can we use custom database for authentication with
NT> Apache instead of default text based authentication???

NT> Has anybody done that before?? I have looked apache site and cpan site..
NT> but couldn't find any documentation...

Look harder.  Particularly at the contributed software area and the
apache module registry.  Or look at the mod_perl based Authentication
and Authorization modules.

Re: may be an offtopic question..

[Matt Sergeant]

7On Wed, 10 May 2000, Niral Trivedi wrote:

> All,
> 
> I am not sure whether this is the right place to ask this question...
> sorry if not..
> 
> My question is, Can we use custom database for authentication with
> Apache instead of default text based authentication???
> 
> Has anybody done that before?? I have looked apache site and cpan site..
> but couldn't find any documentation...
> 
> Can  somebody give me some idea please??
>

I can do better than give you some advice!

http://www.modperl.com/book/chapters/ch6.html

-- 


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org

may be an offtopic question..

[Niral Trivedi]

All,

I am not sure whether this is the right place to ask this question...
sorry if not..

My question is, Can we use custom database for authentication with
Apache instead of default text based authentication???

Has anybody done that before?? I have looked apache site and cpan site..
but couldn't find any documentation...

Can  somebody give me some idea please??

Thanks in advance..

Niral
-- 
Regards...

Niral K. Trivedi, Planet Access Network Inc.
Email : [EMAIL PROTECTED]
Phone : 973-691-4704 x134

Re: [Summation] 100% sessions?

[Jay Jacobs]

On Wed, 10 May 2000, Roger Espel Llima wrote:

> Jay Jacobs <[EMAIL PROTECTED]> wrote:
> >   So as I see it there are essentially 2 *mostly* reliable ways, cookies
> > and url-rewriting.  Both have drawbacks and neither are 100%.  There
> > really isn't a way to cross-reference anything else (IP or login) becuase
> > there are valid reasons for a user to come from multiple ip addresses
> > during a session (albeit rare), and sessions may be needed without
> > requiring a user to login.
> 
> >   It also doesn't make sense to try to rely on both cookies and
> > url-rewriting, that would just get sloppy and waste time.  The only thing
> > to do is to pick one or the other and deal with the drawbacks associated
> > with that...
> 
> Why wouldn't it make sense?  Some users have cookies turned off, then
> you just send them a rewritten URL.  That's what I do now: send a
> session cookie with every request.  If I got a session cookie from the
> client, then that's it; if not, I also add the session data at the end
> of the internal links.

After sleeping on it I agree to a point.  I think the url-session should
be first thing in the url and the site should be fully relatively linked.  
Cookies are a lot "cleaner" for the user and transparent.  So I've written
up pseudo-code (I learned something in college!) on the logic:

User makes request:
  if a cookie exists with session_id
then verify it is a valid session_id
if a session-url exists remove it and rely on cookies
if session is expired   # timed expirations as a security measure
  auth them again if needed and/else redirect to requested page.

  else if a session_url exists with no cookie
verify validity and exipiration as above

  else if no cookie and no url session
new session, set cookie and set session-url
  
  timestamp the session for expiration.


Other notes:
  Having to re-write site-wide urls seems like a bad idea.  It negates any
caching (on both server and client sides), and forces all the pages to be
dynamic.  Relative links (although not the ../../prettiest thing) seems
like the best route.

This way of doing sessions doesn't sit right with me, but I suppose when
your only tool is a hammer...

Jay Jacobs
LachNet Inc.

Re: [Summation] 100% sessions?

[Roger Espel Llima]

Jay Jacobs <[EMAIL PROTECTED]> wrote:
>   So as I see it there are essentially 2 *mostly* reliable ways, cookies
> and url-rewriting.  Both have drawbacks and neither are 100%.  There
> really isn't a way to cross-reference anything else (IP or login) becuase
> there are valid reasons for a user to come from multiple ip addresses
> during a session (albeit rare), and sessions may be needed without
> requiring a user to login.

>   It also doesn't make sense to try to rely on both cookies and
> url-rewriting, that would just get sloppy and waste time.  The only thing
> to do is to pick one or the other and deal with the drawbacks associated
> with that...

Why wouldn't it make sense?  Some users have cookies turned off, then
you just send them a rewritten URL.  That's what I do now: send a
session cookie with every request.  If I got a session cookie from the
client, then that's it; if not, I also add the session data at the end
of the internal links.

-- 
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html

Re: Source Code Shows Up in IE But Not Netscape

[Bri Carey]

> > When I display an .iphtml page in Netscape, everything seems to be fine.
> >
> > When I display it in IE (4.72), I get a plain text output of the source
> > code, including html tags.
> >
> > Why this discrepancy?
>
>IE quite brilliantly ignores the MIME type specified in the header
>in some cases... If you send IE a Content-Type: text/plain
>document that happens to begin with  then it will render it
>as HTML... This sounds like a related problem, but with the opposite 
>effect:
>that is to say, it's now NOT rendering when it should be.

I've tried setting the default type to text/html in the httpd.conf file and 
that didn't seem to do the trick.

I appreciate the input that I've received.

I've also noticed that both browsers display the code, although they format 
the html properly, when I try to execute the script inside of a standard 
.html document.  I know that's not the standard (embedded Perl should have 
.iphtml extensions - at least that's the way it seems to be).  Yes, I have 
made the appropriate changes in the httpd.conf file:

PerlModule Apache::ePerl
   
   Options +ExecCGI
   SetHandler  perl-script
   PerlHandler Apache::ePerl
   

You can see this now at http://www.uncricket.com/index1.html

Thanks again for any input.

Regards,
Bri

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

RE: Registry error

[Geoffrey Young]

see
http://perl.apache.org/guide/troubleshooting.html#Can_t_undef_active_subrout
ine

for a bit of help...

a scouring of the archives also suggests that Apache::SIG has problems with
5.005
(http://forum.swarthmore.edu/epigone/modperl/sniwhoxzer/3.0.5.32.19980805091
[EMAIL PROTECTED])

but that was far before the latest mod_perl release, so you might want to
upgrade to 1.23 if you haven't already...

HTH

--Geoff

> -Original Message-
> From: Jesús Lasso Sánchez [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 10, 2000 3:27 AM
> To: [EMAIL PROTECTED]
> Subject: Registry error
> 
> 
> Hi everybody,
> 
> Does anybody know what is this and how i can resolve it.
> 
> [Tue May  9 22:36:57 2000] [error] Can't undef active subroutine at
> /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/Apache/Regis
> try.pm line
> 102.
> 
> Thank you
> 
>Jesús
> __
> Jesús Lasso - Ya.com Internet_Factory
> [EMAIL PROTECTED]
> www.ya.com - www.jifactory.com
> 

Re: Source Code Shows Up in IE But Not Netscape

[remco]

On Wed, 10 May 2000, Bri Carey wrote:

Hi

> I realize that this is not an ePerl forum, but since ePerl runs as part of 
> mod_perl, I thought it couldn't hurt to at least ask here.
> 
> I must be missing something obvious.
> 
> I've installed Apache::ePerl.
> 
> I've configured httpd.conf according to the instructions:
> 
> 
> Options +ExecCGI
> SetHandler perl-script
> PerlHandler Apache::ePerl
> 
> 
> When I display an .iphtml page in Netscape, everything seems to be fine.
> 
> When I display it in IE (4.72), I get a plain text output of the source
> code, including html tags.
> 
> Why this discrepancy?

Probabaly because IE looks after yor extension instead of your
content-type (if you have any...)
try setting the type ".iphtml" for IE in your registry, this should prove
it...
you will have to use another extension for your files if this is true

> Regards,
> Bri
> 
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
> 

Bye,
remco

/--\
| Remco Schaar |
| e-mail: [EMAIL PROTECTED]  |
\--/

South Park meets Linux:
- "Oh my God, they killed init!"
- "You bastards!"

Source Code Shows Up in IE But Not Netscape

[Bri Carey]

I realize that this is not an ePerl forum, but since ePerl runs as part of 
mod_perl, I thought it couldn't hurt to at least ask here.

I must be missing something obvious.

I've installed Apache::ePerl.

I've configured httpd.conf according to the instructions:


Options +ExecCGI
SetHandler perl-script
PerlHandler Apache::ePerl


When I display an .iphtml page in Netscape, everything seems to be fine.

When I display it in IE (4.72), I get a plain text output of the source
code, including html tags.

Why this discrepancy?

Regards,
Bri

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: Wierd error log entry:

[Matt Sergeant]

On Wed, 10 May 2000, Ken Williams wrote:

> Perhaps it's the result of a line like "require 5.0;"?  That's the only
> thing I can think of, I've never seen it before.

Maybe... I wonder what would cause that to a) go in %INC, and b) go out of
date...

Ah well. Server restart got rid of the error :)

-- 


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org

Re: Wierd error log entry:

[Ken Williams]

Perhaps it's the result of a line like "require 5.0;"?  That's the only
thing I can think of, I've never seen it before.


[EMAIL PROTECTED] (Matt Sergeant) wrote:
>Apache::StatINC: Can't locate /usr/lib/perl5/site_perl/5.0 at
>/usr/lib/perl5/site_perl/5.005/i386-linux/Apache/StatINC.pm line 19.
>
>Granted this is a development server and I do some wierd stuff, but that's
>just bizarre... Any ideas?

RE: Wierd error log entry:

[Leon Brocard]

Matt wrote:

> Apache::StatINC: Can't locate /usr/lib/perl5/site_perl/5.0 at
> /usr/lib/perl5/site_perl/5.005/i386-linux/Apache/StatINC.pm line 19.

"use 5.0" going wrong somewhere and getting inserted into %INC?

Leon
--
Leon Brocard   |   perl "programmer"   |   [EMAIL PROTECTED]

RE: Wierd error log entry:

[Geoffrey Young]

for what it's worth, I've seen that on my development box too - I usually
just do a stop and start instead of relying on StatINC when the error is
frequent...

--Geoff

> -Original Message-
> From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 10, 2000 7:56 AM
> To: [EMAIL PROTECTED]
> Subject: Wierd error log entry:
> 
> 
> Apache::StatINC: Can't locate /usr/lib/perl5/site_perl/5.0 at
> /usr/lib/perl5/site_perl/5.005/i386-linux/Apache/StatINC.pm line 19.
> 
> Granted this is a development server and I do some wierd 
> stuff, but that's
> just bizarre... Any ideas?
> 
> -- 
> 
> 
> Fastnet Software Ltd. High Performance Web Specialists
> Providing mod_perl, XML, Sybase and Oracle solutions
> Email for training and consultancy availability.
> http://sergeant.org http://xml.sergeant.org
> 

Wierd error log entry:

[Matt Sergeant]

Apache::StatINC: Can't locate /usr/lib/perl5/site_perl/5.0 at
/usr/lib/perl5/site_perl/5.005/i386-linux/Apache/StatINC.pm line 19.

Granted this is a development server and I do some wierd stuff, but that's
just bizarre... Any ideas?

-- 


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org

Re: [OT] Re: 100% sessions?

[Stas Bekman]

> Stas, this thread is very interesting.  Guide material?

Yeah, sure. Someone would like to summarize things in a verbose form?

Thanks a lot!

__
Stas Bekman | JAm_pH--Just Another mod_perl Hacker
http://stason.org/  | mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]  | http://perl.orghttp://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
--

Re: Using -w in a package

[Stas Bekman]

On Wed, 10 May 2000, Scott Alexander wrote:

> Hi,
> 
> I've used #!/usr/bin/perl -w in all of my scripts
> 
> but how can I use -w in a package ?
> 
> I have always declared variables with my in a sub but speling mistakes will 
> happen. And I don't get any warnings. How can I do this?

http://perl.apache.org/guide/porting.html#Command_line_Switches_w_T_e

> 
> regards and thanks in advance
> 
> Scott
> 
> 
> Scott Alexander tietoverkkosuunnittelija
> [EMAIL PROTECTED]
> gsm: +358 (0)40 7505640
> 



__
Stas Bekman | JAm_pH--Just Another mod_perl Hacker
http://stason.org/  | mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]  | http://perl.orghttp://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
--

Re: [Summation] 100% sessions?

[Matt Sergeant]

On Wed, 10 May 2000, Jay Jacobs wrote:

>   So as I see it there are essentially 2 *mostly* reliable ways, cookies
> and url-rewriting.  Both have drawbacks and neither are 100%.  There
> really isn't a way to cross-reference anything else (IP or login) becuase
> there are valid reasons for a user to come from multiple ip addresses
> during a session (albeit rare), and sessions may be needed without
> requiring a user to login.
>   It also doesn't make sense to try to rely on both cookies and
> url-rewriting, that would just get sloppy and waste time.  The only thing
> to do is to pick one or the other and deal with the drawbacks associated
> with that...
> 
> URLS:
> - redirecting to a different site sends the session_id in the
> HTTP_REFERER in some browsers, which ruins it for the rest of the world ;)
> - requires site-wide url-rewriting or site-wide relative links (including
> things like "../../index.html" which seems ugly IMO)

If you're doing site-wide URL re-writing, you might as well re-write
outside URL's to a redirect CGI, so that the session doesn't go in the
referer.

-- 


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org

Re: configuring Apache::Session to detect no-cookie browser

[David . Lamkin]

> Hi,
> 
> After reading an interesting thread here about session management I
> would like to detect if the user's browser refuses cookies and switch
> Apache::Session from cookie mode to URL mangling mode.
> 
> Has someone already tackled this and would be so kind to share the
> solution?
> 

We are playing around with this at the moment in a mason based site: what we
do is..

If a request comes in with no session id (either in cookie or path): check
list of "cookies sent to" browsers (keyed by client ipaddress). If we haven't
seen this host recently (we currently remember the last 50 cookie attempts)
then attempt to issue a cookie, otherwise insert a session id at head of path.

If we apparently have a session id in the request, validate the requestor
session (we don't want to force users to login for the free part of the site:
we would rather tease them in & get them to register sometime later) by :

1. checking session is still active
2. checking {remoteip address,User-Agent} for user with that stored in the
session database in case a path based session has been passed between users.

If these checks fail then initiate a new session.

We have a further wrinkle on this in that we attempt to detect visits from
search engine trawlers by looking at the User-Agent field & never use path
based sessionids for them (they mostly don't return cookies) -- I didn't like
the idea of publishing sessionids on search engine listings. Because of their
usage pattern & with a bit of care in the use of session data we have
constructed a site which still works when entered at any page with a virgin
user session.

For 'sensitive' areas of the site the user must validate themselves against
the session they purport to be using.

All in all this is very tedious!

regards,
David Lamkin
[EMAIL PROTECTED]

Re: [Summation] 100% sessions?

[Robin Berjon]

At 02:24 10/05/2000 -0500, Jay Jacobs wrote:
>  So as I see it there are essentially 2 *mostly* reliable ways, cookies
>and url-rewriting.  Both have drawbacks and neither are 100%.

Well if it's *reliability* that you are looking for, url rewriting seems to
come-accross as better. None of the following points really keeps you from
implementing a quite reliable scheme, depending of course on the level of
security that you want.

>URLS:
>- redirecting to a different site sends the session_id in the
>HTTP_REFERER in some browsers, which ruins it for the rest of the world ;)

Writing a handler that sends a proper redirect to browsers known to handle
it correctly and a  redirect to the rest takes only a few lines of
code. I know the latter isn't the most beautiful solution but hey, dirty
browser, dirty solution :)

>- requires site-wide url-rewriting or site-wide relative links (including
>things like "../../index.html" which seems ugly IMO)

url-rewriting can be costly, but it isn't really hard to do. And there are
advantages to relative linking.

>- users bookmarking with the session_id which may be expired on the server
>side thus negating the bookmarked session.

Well, either the session is still valid (as it would be for instance with a
long-lasting cookie) and there isn't a problem, or it isn't and the user
should log in again, or be redirected to another url with a proper session.

>- messes up logging unless a custom logging handler, or url-rewriting
>before logging is implemented

Again that isn't hard or long to do.

I'm not trying to say that your points are wrong and that having to
implement all this is not troublesome, but url rewriting seems to me to be
pretty reliable, at least compared to cookies. The user can still try to
delete the session from the url, but that's the same problem with cookies.
Suffice it to say cookies are *much* more likely to be off than urls :)
It's more a question of doing it cleanly and efficiently than reliably imho.

There are also things that can be done with domain levels under the second
(eg: ses465738.domain.com) that take care of points 2 and 4 (but it's ugly).



.Robin
Forty two.

configuring Apache::Session to detect no-cookie browser

[Louis-David Mitterrand]

Hi,

After reading an interesting thread here about session management I
would like to detect if the user's browser refuses cookies and switch
Apache::Session from cookie mode to URL mangling mode.

Has someone already tackled this and would be so kind to share the
solution?

TIA

-- 
Louis-David Mitterrand - [EMAIL PROTECTED] - http://zzz.apartia.org/ldm/

Re: Bitten by -D_FILE_OFFSET_BITS=64

[Alan Burlison]

"Paul G. Weiss" wrote:

> This has been fixed in a post 1.23 patch.
> Change the line
> 
>  $PERL_EXTRA_CFLAGS = "";
> 
> to
> 
>  $PERL_EXTRA_CFLAGS = $] >= 5.006 ? $Config{ccflags} : "";
> 
> and try again.

Note that this is not a complete fix.  It will only work if you allow
mod_perl to build apache, as instructed in the original patch. 
Unfortunately if you are using APXS this is not the case.  In this case,
when you initially build Apache you need to do so with the flags
required to make it largefile aware.  I think it might also be a good
idea to put a test in mod_perl's Makefile.PL to check that the
largefile-ness of both perl and apache agree when using APXS.  On
Solaris you can do this by using nm and looking to see if the normal or
largefile versions of routines are in use, e.g. fstat or fsta64.  I
don't know how portable to other platforms this is though.

-- 
Alan Burlison

RE: 100% sessions?

[Leon Brocard]

Rodney Broom:

> I've been thinking for a while now on a "complete" state maintainance
> system. Although it would be allot of writing, I think that a 
> system could be build that magically incorporates one or more of:
> - magic numbers (or session IDs)
> - cookies
> - IP tracking
> - special form vars

It strikes me that a module derived from CGI.pm (overloading self_url,
end_form and the cookie methods) would be able to handle this almost
transparently. 

Turns out a couple of modules on CPAN kinda do this already:

  o CGI::Persistent - Transparent state persistence for CGI applications. 
  o CGI::Seamstress - CGI extension supporting all programmatic...

So who's volunteering? Leon
--
Leon Brocard   |   perl "programmer"   |   [EMAIL PROTECTED]

Using -w in a package

[Scott Alexander]

Hi,

I've used #!/usr/bin/perl -w in all of my scripts

but how can I use -w in a package ?

I have always declared variables with my in a sub but speling mistakes will 
happen. And I don't get any warnings. How can I do this?

regards and thanks in advance

Scott


Scott Alexander tietoverkkosuunnittelija
[EMAIL PROTECTED]
gsm: +358 (0)40 7505640

Re: segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12

[Alan Burlison]

Michael Poole wrote:

> In hopes that this would fix the APXS build, I tried rebuilding with
> that, but whenever the httpd tried to load the php3 or perl module, it
> would die in pthread_mutex_lock.  This was slightly odd, since php3
> would load fine when httpd was statically linked against mod_perl.
> For the time being, I'll just roll back to using static mod_perl and
> dynamic mod_ssl and php3.

No, that's what you would expect.  The problem is being caused because
perl amd mod_perl are being built to be largefile aware, whereas by
default Apache is not.  By following Doug's instructions to let mod_perl
build httpd you are building it with the same flags needed to make
perl/modperl largefile aware, so Apache too ends up being largefile
aware and all the bits then are in sync.

If you use APXS you are building Apache seperately and with the standard
config, i.e. not largefile aware, so it breaks.  If you want to use APXS
you have to build Apache to be largefile aware yourself.  On Solaris at
least the way to do this is to set CFLAGS='-D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64' in your environment before invoking the Apache
configure.

-- 
Alan Burlison

hang with $r->internal_redirect

[Louis-David Mitterrand]

I am trying an internal_redirect from a POST with Mason and Apache just
hangs:

$r->method('GET');
$r->method_number(M_GET);
$r->headers_in->unset('Content-length');
$r->internal_redirect_handler("/wronglogin.md");
$m->abort(302);

However when I try an internal_redirect from a GET it works but HTTP
headers are sent twice (at least) and get printed in the HTML page.

Any idea what's going on?

TIA

-- 
Louis-David Mitterrand - [EMAIL PROTECTED] - http://www.apartia.com
Debian-Linux consulting: http://www.apartia.fr

 "There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence." - Jeremy S. Anderson

Registry error

[Jesús Lasso Sánchez]

Hi everybody,

Does anybody know what is this and how i can resolve it.

[Tue May  9 22:36:57 2000] [error] Can't undef active subroutine at
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris/Apache/Registry.pm line
102.

Thank you

   Jesús
__
Jesús Lasso - Ya.com Internet_Factory
[EMAIL PROTECTED]
www.ya.com - www.jifactory.com

Re: [Summation] 100% sessions?

[Jay Jacobs]

  So as I see it there are essentially 2 *mostly* reliable ways, cookies
and url-rewriting.  Both have drawbacks and neither are 100%.  There
really isn't a way to cross-reference anything else (IP or login) becuase
there are valid reasons for a user to come from multiple ip addresses
during a session (albeit rare), and sessions may be needed without
requiring a user to login.
  It also doesn't make sense to try to rely on both cookies and
url-rewriting, that would just get sloppy and waste time.  The only thing
to do is to pick one or the other and deal with the drawbacks associated
with that...

URLS:
- redirecting to a different site sends the session_id in the
HTTP_REFERER in some browsers, which ruins it for the rest of the world ;)
- requires site-wide url-rewriting or site-wide relative links (including
things like "../../index.html" which seems ugly IMO)
- users bookmarking with the session_id which may be expired on the server
side thus negating the bookmarked session.
- messes up logging unless a custom logging handler, or url-rewriting
before logging is implemented

Cookies:
- Turned off by user
- May be blocked all together by some proxies.

I'm sure I missed some points, but it's all I can think of at this
time.

Jay Jacobs
LachNet Inc.