Re: talking about cookies (was: session something...)
At 07:28 PM 5/12/00 +0300, Stas Bekman wrote: >On Fri, 12 May 2000, Keith G. Murphy wrote: > > > "Jeffrey W. Baker" wrote: > > > > > > On Thu, 11 May 2000, Marc Slemko wrote: > > > > > > > In reality, IE's recently publicized hole (which I reported to > them, in a > > > > slightly modified form, months ago but they didn't see fit to release a > > > > patch...) doesn't change much. > > > > > > > > Hotmail? Yahoo mail? amazon.com? etc. Your cookies for all > those sites > > > > are vulnerable anyway due to the "cross site scripting" issue. This > > > > particular hole in IE doesn't change things too much. Sure, there > may be > > > > the rare site that isn't vulnerable to cross site scripting. But > that is > > > > the very rare site, and most sites that think they aren't > vulnerable are. > > > > > > > > Cookies are not secure and will never be secure. I have said it before > > > > and will say it again many times before I die. Unfortunately, it > isn't as > > > > simple as saying "well, don't use cookies". There isn't much in > the way > > > > of alternatives for a lot of things... > > > > > > Cross-site scripting attacks are hard for most people to wrap their minds > > > around. There are a zillion sites that are vulnerable, mainly because > > > they parrot back to the user whatever they submitted without doing any > > > validation or HTML/URL escaping. Then there are browser bugs that don't > > > treat excaped character properly. Sigh. > > > > > Whether we're talking about the IE bug, or cross-site scripting issues, > > wouldn't the whole thing be solved by users turning *off* scripting and > > leaving the cookies *on*? I.e., in what ways are cookies not safe if > > scripting is turned off? > >You are absolutely right. The question is who is going to explain this to >users, MS? MS Marketing engine is very strong and people get shocked when they read something like that, but expedience says that most poeple think "Well, it probably wont happen to me". For example... Just because IIS itself has a lot of holes doesn't mean that some of the top financial institutions don't use it for the websites (do a random probe of financial SSL sites with Netcraft's utility)... In fact, they probably love the holes because they get publicity and the people with money remember the brand but rarely remember the techie details of the problem. "Well as long as it was fixed, we should be able to run IIS now right?". :) > > [snipped] > > > But it does seem like not even MS is saying "Don't accept cookies". > > Though they're still pretty quiet on the latest IE hole. > >Heh, you probably have never didn't do support :) it's enough for them to >see the two words: "cookies" and "evil" in the same sentence, you know how >most of them will conceive it, you shouldn't think twice. I doubt they >know what "scripting" is. Also remember the bad history cookies carry with >them. Although I am sure there are people who turn off cookies, I believe that there are many more people who couldn't care less and will leave them on. However, I do concede that forcing users to use cookies for an open internet site is silly. And it is becoming a lot sillier for eCommerce as technologies like PDAs become more prevalent for people doing quick searches and the like on the Web (PDAs typically do not implement cookie capabilities) __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Problem with @INC
Hi,
Simple problem, I had a quick search thorugh the archives and a good delve into the
perl website, no joy.
(Using modPerl 1.23)
#!/usr/bin/perl -w
use lib '../site_perl';
use CGI;
my $cgi = new CGI;
print $cgi->header;
print join("\n", @INC);
---
First time (compiling run):
../site_perl
/usr/lib/perl5/5.00503/i386-linux
/usr/lib/perl5/5.00503
/usr/lib/perl5/site_perl/5.005/i386-linux
/usr/lib/perl5/site_perl/5.005
.
/etc/httpd/
/etc/httpd/lib/perl
Second run :
/usr/lib/perl5/5.00503/i386-linux
/usr/lib/perl5/5.00503
/usr/lib/perl5/site_perl/5.005/i386-linux
/usr/lib/perl5/site_perl/5.005
.
/etc/httpd/
/etc/httpd/lib/perl
---
In other words my 'use lib' line disappears. I can understand why. You typically won't
need it after
it's already been compiled. I've been happily using modPerl for ages and this
hasn't caused a problem. My company however newly requires that I speak to 25
different credit card
processors and I wanted to pull them in with 'eval "require $classname"' statements
like LWP does
with net protocols. For efficency
I'd like to compile them when needed not in bulk on the first run.
I'd also prefer not to put my libraries in the system library area as it defeats my
development
setup of having test and beta libraries on the same machine.
I've got a workaround (I force them all to load on the first run if under modPerl),
however I
thought I'd post, might be something for the developers to think about.
Cheers,
Robert Nice
Technical Director
WebsiteBilling.com Inc
Undefined DESTROY() in error_log
I see this error message in my error_log, [Sat May 13 13:06:38 2000] [error] (in cleanup) Undefined method HTML::FastTemplate::DESTROY at /usr/lib/perl5/site_perl/5.6.0/i686-linux/Apache/Registry.pm line 144 Does it mean that I have to add a dummy DESTORY() in my package? Is there any docs discussing this already? Kenneth
Re: Oops Re: ANNOUNCE: mod_perl guide version 1.23
Missing the cyan and purple already :) Heh, not really, looks much more professional now - in the past I would sometimes close the guide down when management walked past as it looked non-work related from a distance. Not sure yet if I preferred the code and configuration snippets with a different colour background, did make it easy to find what your looking for when scrolling quickly, but overall a great job once again - and I'm sure I'm not alone on this list when I say "Thanks Stas for your efforts" :) Mental note - will have to snag the 1.23 HTML guide download when available - it was a real pain yesterday when I coudn't access apache.org (down for some reason? hacked again?). > Oops sorry for the typo... something is wrong with me... really > > It's the guide... not mod_perl... luckily mod_perl 1.23 was already > announced :) > > Enjoy!
Re: Oops Re: ANNOUNCE: mod_perl guide version 1.23
On Sat, 13 May 2000, Martin Wood wrote: > Missing the cyan and purple already :) > > Heh, not really, looks much more professional now - in the past I would > sometimes close the guide down when management walked past as it looked > non-work related from a distance. > > Not sure yet if I preferred the code and configuration snippets with a > different colour background, did make it easy to find what your looking for > when scrolling quickly, but overall a great job once again - and I'm sure > I'm not alone on this list when I say "Thanks Stas for your efforts" :) Thanks! I'll see if I can arrange back the distinct bg color for the code snippets, some light shade of grey may be. Special thanks of course go to Mark Summerfield and Ged Haywood who spend a significant slice of their free time reviewing and correcting the Guide. Thank you folks! > Mental note - will have to snag the 1.23 HTML guide download when > available - it was a real pain yesterday when I coudn't access apache.org > (down for some reason? hacked again?). Nope, the machine was restarted and httpd didn't start. It took a while before the guy with the root password came in to fix it. This shouldn't happen again. The "problem" was caused by Apache running for years without any problems, so no one was prepared for a need to have a root access :) Remember that if you want to grab the HTML version, you do: perl -MCPAN -e shell cpan> install Apache::mod_perl_guide __ 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: Best approach for loading several modules
Thanks for the tip - its something I will definitely explore. My entire gripe with this problem has not been with performance or efficiency but with readability and easy maintainability of the many scripts in our main application - but we are getting there - and the great thing is there are so many options. Our current proprietary system (which embeds a C/BASIC type language in the HTML pages) doesn't scale well no matter how much hardware we throw at it, but has the benefit of having all the "messy" stuff like middleware and database connections, session handling etc. hidden away. It will be a case of culture shock for the developers to suddenly have to explicity include all the modules they need and perform all the initialisation stuff - so we are trying to make it as simple as possible to migrate, without a large increase in the size of the scripts. > Are you using OO perl and inheritance? I'm late on this thread, but what > about use'ing a common module which then use'es all the other modules > you need? It's well worth the effort IMHO... > > I realise the actual code isn't duplicated - but the script itself still > > needs the list of "use" directives regardless of whether you pre-load them > > and there doesn't seem to be an easy way to factor this common block of > > unsightly directives out into one file for use in multiple scripts that > > share the same resources.
Re: Problem with @INC
On Sat, 13 May 2000, Robert Nice wrote:
> Hi,
>
> Simple problem, I had a quick search thorugh the archives and a good
> delve into the perl website, no joy.
You didn't delve deep enough, perl.apache.org/index.html reveals no
mod_perl specific info.
Guide is your guide into mod_perl. The answer to your question is there:
http://perl.apache.org/guide/porting.html#_INC_and_mod_perl
> (Using modPerl 1.23)
>
> #!/usr/bin/perl -w
>
> use lib '../site_perl';
> use CGI;
>
> my $cgi = new CGI;
> print $cgi->header;
> print join("\n", @INC);
> ---
> First time (compiling run):
> ../site_perl
> /usr/lib/perl5/5.00503/i386-linux
> /usr/lib/perl5/5.00503
> /usr/lib/perl5/site_perl/5.005/i386-linux
> /usr/lib/perl5/site_perl/5.005
> .
> /etc/httpd/
> /etc/httpd/lib/perl
>
> Second run :
> /usr/lib/perl5/5.00503/i386-linux
> /usr/lib/perl5/5.00503
> /usr/lib/perl5/site_perl/5.005/i386-linux
> /usr/lib/perl5/site_perl/5.005
> .
> /etc/httpd/
> /etc/httpd/lib/perl
> ---
>
> In other words my 'use lib' line disappears. I can understand why. You typically
>won't need it after
> it's already been compiled. I've been happily using modPerl for ages and this
> hasn't caused a problem. My company however newly requires that I speak to 25
>different credit card
> processors and I wanted to pull them in with 'eval "require $classname"' statements
>like LWP does
> with net protocols. For efficency
> I'd like to compile them when needed not in bulk on the first run.
> I'd also prefer not to put my libraries in the system library area as it defeats my
>development
> setup of having test and beta libraries on the same machine.
> I've got a workaround (I force them all to load on the first run if under modPerl),
>however I
> thought I'd post, might be something for the developers to think about.
>
> Cheers,
>
> Robert Nice
> Technical Director
> WebsiteBilling.com Inc
>
_
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.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
