Re: [OT] Inspired by closing comments from the UBB thread.
I'd second the original question, I've always embedded the SQL (what's the S for?) in the code, isn't that the point of the wonderful DBD::* packages? As far as modularizing database calls, there are a couple reasons I've had problems with that. I found the methods being rewritten to handle about as many options as sql itself. (what if I want to sort differently? what if I need a slightly different statement?). My solution is to embed SQL most of the time, modularize basic calls (get_user, get_group type stuff). In addition, I'd like to rebut the original statement: not to mention the HTML embedded all throughout the perl (are they on glue?) What's the alternative there? Embed perl in the HTML? On Wed, 1 Aug 2001, Barry Hoggard wrote: I think a lot of people's approach, including mine, is to have OO Perl modules for all database access. In my code (I use Mason), a web page only gets its data through calls like this: my $obj = NAIC::User-(DBH=$dbh, EMAIL='[EMAIL PROTECTED]'); $obj-load; my $groups_list = $obj-groups(); That way any needed SQL changes, or even ports to a new database, don't have to be done everywhere in my code. On Wed, Aug 01, 2001 at 10:12:45AM -0500, Joe Breeden wrote: All, In his closing comments about UBB Kyle Dawkins made a statement that got me wondering. He said there's SQL embedded all throughout the Perl everywhere (who does this?! oh my god, are they on crack?). ... It would be interesting to know how other people have solved that problem. Currently, we are essentially using embedded SQL in our apps. -- Barry Hoggard
Re: [OT] Inspired by closing comments from the UBB thread.
I wasn't clear enough... My point was more six one way, half dozen the other. For a public package, keeping dependancies down to a minimum is a bonus, as well as keeping performance up by not having to pre-process html looking for perl code. It can come down to a choice between maintainability and better performance (to whatever degree). I don't see any glue-sniffing symptoms from choosing embedded html in perl over embedded perl in html. Jay On Wed, 1 Aug 2001, Perrin Harkins wrote: not to mention the HTML embedded all throughout the perl (are they on glue?) What's the alternative there? Embed perl in the HTML? You could do that (Text::Template), or you could use a tool like Template Toolkit or HTML::Template. See http://perl.apache.org/features/tmpl-cmp.html for a description of the available options. - Perrin
Re: [VERY OT] Inspired by closing comments from the UBB thread.
On Wed, 1 Aug 2001, Kyle Dawkins wrote: Mixing HTML with Perl with SQL is bad and evil on every single possible level. This bugged me... TMTOWTDI applies on so many levels. The right way to do something is not always the technically best way to do something. If you work in a large corporate enviroment with many hands in the development pot, then hey, I agree, and there should probably be a corporate document stating the guidelines and restrictions of developement. If however you work in a two person company where you have barely enough time to go to the bathroom let alone think about creating your own database abstraction layer for a custom application and maintaining code means changing a link once a month. Then by all means embed away, and take the quick development path over performance or maintainability. On the other hand, if you are completely broke and work on a non-profit project and the only system you have is a P200 with 64M of Memory, then you may want to think about avoiding templating systems, and doing nothing but a single module with embedded SQL with Perl and HTML. There is always more then one way to do it, and there's usually more then one right way to do it. Let's keep that in mind. Jay
Re: [VERY OT] Inspired by closing comments from the UBB thread.
My apologies for beating this dead horse... I am just unable to get my point across at all today. On Wed, 1 Aug 2001, Kyle Dawkins wrote: Tom et al. This is, in my opinion, circular logic. Perhaps the reason that you barely have enough time to go to the bathroom is that you're writing the code the wrong way. :-) ...my point with that scenario was that there is just too much work to spend the time writing highly maintainable code that has only the simplest of maintance tasks. Just because we use free and/or open source tools to build our code, doesn't mean we can write crap. We have an obligation to do our duty to whomever we work for, and LEARN and apply that learning to our work. There is always more then one way to do it, and there's usually more then one right way to do it. Let's keep that in mind. Agreed. However, Perl + HTML + SQL isn't one of the right ways! :-) Couldn't agree more. Just because TMTOWDI doesn't mean that all of those ways are equal. Most ways suck, in fact. Granted, the world is full of incompetance, but if you spent your time coding for a perfect world in every situation, you could still be working on the write-up while the next guy is collecting the check for a finished project and bidding on the next project, might not be bad code, might be really good code, might really suck, who cares, it works, the customer is happy and both businesses do well, the down side is some geek may have to maintain it but they'll get to complain about crappy code and show their rightousness on a public mailing list. Don't get me wrong here, I agree with the perfect code... I'd absolutely love to see a clean solution to embedded html/perl/sql that has fast performance, fast development and easy maintainability. I wish that the technically best way always matched the right way. And us righteous developers decided how the world was run. But my misintrepreted point is that there are situations in which this version of perfect code has no place, even if I can't write them up in an email.
Content-Disposition to change type and action?
I've got a form that will (should) send various formats back to the client depending on form values. They may want the results back in csv, pdf or plain html. The form always submits to a .html, and the browser usually expects an html. I've tried setting $r-content_type and even $r-filename to try and get the browser (ie 5 for now) to see it as a non-html file and do the right thing. Then I came across setting Content-Disposition: $r-header_out(Content-Disposition, attachment;filename=\ticket_search.csv\); This has an unexpected result, I get a pop-up asking me what I want to do with the html document (save/exec), if I exec it, it asks me what I want to do with the csv (save/exec). I've never run across Content-Disposition, anyone have a listing of what it does and the options? How do other out there return other mime-types when text/html is requested? Jay
Re: Content-Disposition to change type and action?
Ken's right and yeah, I wanted to stay away from Javascript and keep it simple, it's not the doing of javascript that's bad, it's the redoing. One thing that appears to work is setting the Content-Disposition header value to inline;filename=\search.csv\. (instead of attachment). IE5 seems to do the right thing with that, it pops up one box saying what would like to do with search.csv?. Doing a redir might be a better option then to trust IE4 and NS+ to do it correctly... not to mention trusting IE6 to do anything like IE5. Thanks for the help, Jay On Tue, 29 May 2001, Ken Williams wrote: [EMAIL PROTECTED] (Steve Piner) wrote: My suggestion is to use mod_rewrite to create a mapping so that the actual file name doesn't matter. I have a rule in the Apache conf file: RewriteRule ^/reports/ /bin/report.pl [PT] So going to http://www.mysite.com/reports/foo.csv?param1=val1 would be the same as going to http://www.mysite.com/bin/report.pl?param1=val1 except if the page is to be downloaded, the browser will use the name foo.csv. That doesn't solve the problem, though. The type of file is chosen in a form, and the action of the form is already set by the time that form is loaded. I assume Jay doesn't want to use Javascript to change the action dynamically. My own preference would be to post to some generic script which redirects to another URL with the desired filename extension and proper disposition headers. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Appending Sessionid to all the urls
Yeah, create a safe link jumping point. Something that you'd link to instead of the external link, and pass in the external link, without a session_id so that the HTTP_REFERER won't have the session ID. Don't rely on IP address for more reasons then you mentioned... It might not hurt to implement some kind of time out feature too. It's you and a dagger against an army. Jay On Thu, 24 May 2001, stefan weiss wrote: From: [EMAIL PROTECTED] A better way for session ids is to put them in front of the URI: http://www.nus.edu.sg/dfd3453/some/path/and/file.html (...) These session ids are sticky as long as you only use relative paths in your html. Note: You may want to put your images in a directory that's not covered by this handler and use absolute paths... But wouldn't the session ID get sent to other (possible malicious) servers as well - in the HTTP_REFERER, if the user clicks on an external link? That might enable a script on that other server to grab your user's session. I guess you could add an additional check including the original user's IP address, but that's not really safe either. People working in the same company could spy on each other if they use the same HTTP proxy. Any known workarounds for this? cheers, stefan
Re: Appending Sessionid to all the urls
there's always more then one way...
DocumentRoot /usr/local/apache_mp/htdocs
RewriteEngine On
RewriteCond /usr/local/apache_mp/htdocs/%{REQUEST_FILENAME} !-f
RewriteRule /?S=([^/]+)/(.*) /$2 [E=SESSION_ID:$1]
This sets $ENV{SESSION_ID} to the session ID, but also catches it, if by
some bizarre and unlikely circumstance your have a directory that matches
someone's Session ID. In this case the session is:
http://host.domain.com/S=asdfasdf/path/requested.pl
Using mod rewrite also munges the $r-filename which helped things like
mason that looked for it (don't know if it still does).
Jay
On Tue, 22 May 2001, Joachim Zobel wrote:
At 18:06 22.05.2001 +0800, you wrote:
For instance when i access url
http://www.nus.edu.sg?sessionid=dfd3453http://www.nus.edu.sg?sessionid=dfd3453
i want all the urls to be appended in all the urls of that website..
My qns is everytime i found that the session id is lost... through the
many requests and responses.
And the new url does not reflect on the client browser..
Any one got any idea.. what wrong with my program??
Wrong concept.
Use a sid in the URL path like
http://www.nus.edu.sg/sessionid-dfd3453/this/is/it.pl
Use mod_rewrite to remove /sessionid-\w+
Use only relative links.
Thats it. You can get the sessionid by parsing $ENV{REQUEST_URI}
Hth,
Joachim
--
... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden
koennen.- Bertolt Brecht - Leben des Galilei
Re: [OT] Perl Script Source Code...
On Tue, 9 Jan 2001, G.W. Haywood wrote: Hi Allysson, On Tue, 9 Jan 2001, Allysson Flavio wrote: Is there a way to put in our client's server only compiled scripts or like??? Or can we change Perl source code to decript our files?? I think you'd better read a book about C. Hi everybody else, Just asking, but am I the only one that gets a really bad feeling when people want to use Open Source Software to do things like this? It seems kinda counter to the spirit of it all somehow. 73, Ged. I'd hope you're the only one, either that or I missed your point. Do you get paid for coding in perl? How is that different then coding in perl then wanting to sell the software and try to maintain rights and privacy on your creation? I don't think C is a good point to bring up either, isn't gcc open-source software? It just so happens that C has built in protections for source-code theft, and perl doesn't. I don't think it makes a bit of difference what tools you use, you should be able to take whatever steps you think are necessary to protect your work. as a side note, I've never felt a need to protect my perl source like aforementioned, but I can think of a few circumstances where "protecting source" is different the "hording the source". You may just want to keep the code covered to make it a little harder for someone (with a lot more time then you) to figure out how to break it, you may want to hide a hard-coded password, or just keep things black to stop folks from wandering through because you wrote the application in 5 minutes between phone calls and meetings and you're emberrassed you put out such awful code, but it works, so run it. Jay
Re: Mod_perl tutorials
snip all other notes on it I've seen a few folks say "my tuturial is at http://xxx", etc. But it would be great if someone could put them all in a single place (take23?) with a blurb about each. I've been trying to keep the email with the links to the various presentations and tutorials for the moment when I have time to look at them, but it'd be great to have a single location that I might have in my memory when time is available. Jay
Re: [me too] certification [Was: mod_perl advocacy project resurrection]
On Wed, Dec 06, 2000 at 01:22:26PM -0800, Randal L. Schwartz wrote: I mean, until I can demonstrate that people with certs are likely to get hired faster or make more money, what's the point? As it is now, good mod_perl people are hard enough to find that the jobseeker already has the advantage. "The jobseeker already has the advantage" is the key phrase. I think the general idea is to balance that out and broaden both the job market for mod_perl folks, and the talent pool of mod_perl programmers. At this point, IMO certification is the end of the line, the destination. What we need is a path to the destination. We want to generate enough interest and (dare I say) marketability of mod_perl to warrant certification. Articles are helpful, but when was the last time you saw a corporate big-wig reading TPJ or Perl Month? I'm sure it happens, but what about getting an article in the big trade rags? Slipping something in Ziff-Davis rags, the things that sit on their desk and coffee tables... I'd take a list of activities from your website, complete the activities, submit my code back to you, and let you grade me, snip Copy and paste works wonders in the web. You'd need heavy code-commenting or a detailed explanation from the person (preferably in person) of the code they "wrote". It's the right path, just need to prepare for the lowest common denomenator. I'd be a little less eager about the sort of simple multiple choice that would be easiest to automate, but even that would suffice. Or a good combination thereof. I would love to be able to list on my resumé that I was Perl and mod_perl certified. How about publicity in the form of a page listing certified Perl/modPerl coders on take23, with contact info if they like? Great for getting those job offers. From an employer's standpoint, that's an awful statement to read. If I hire a certified perl/mod_perl person, I'd like to believe that they're with my company, and not reviewing other job offers continually, if the site could evolve to "available certified folks"... that would be a much better solution. See point #1 above. Jay Jacobs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Certification
On Thu, 7 Dec 2000, Matt Sergeant wrote: On Thu, 7 Dec 2000, J. J. Horner wrote: If I'm way off base, please let me know. I'm spending considerable brain power on this idea and if I'm wasting it, I need to know. I don't have much spare brain power and I could use it to try to figure out my wife . . . Ask yourself this question: Are you in need of a mod_perl job? If so, I'm willing to bet that there are employers who would snap you up in a second. snip On the flip side, if you're an employer looking for a good mod_perl programmer, they're hard to find, and if you do find them, they're quirky. ;) I liked the idea of incorporating the local perl mongers groups into the teaching/training/advocacy process. I proposed it to my local group as a possibility. Perhaps it would help to get some standards though (similiar to a certification process) that the groups could follow. Perhaps areas to cover, standard tests, etc. Things that would lead a person to getting really certified when/if such a thing exists. Jay Jacobs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Stas Bekman wrote: What we want is very simple. 1. We want many users, so they will thoroughly test the software and spot bugs asap, so we -- current users will get a better product. 2. We want more developers, so they will write core mod_perl and 3rd party modules, again for us current users to re-use and save development time. The first item is directly linked to the second, as new developers come out from users. I think a good first step in that direction is to have mod_perl modules to do some of the basic things that early web developers want... a few really well documented and tailored-for-newbies modules. I think back a few years to "Matt's Script Archive", and what that did for perl and CGI. (Anyone for Apache::Formmail?) Just some stuff to get the new developer interesting in figuring out how to compile mod_perl, and to see the benefits of it. It could even be done with step-by-step examples, with gradually increasing functions. ( "Now move on to Guestbook-DBI" ... "Now add in Apache::Session for such-n-such functions" ) Perhaps even offer the same modules under mason, embperl axkit, etc. so folks can take a step in those directions too. I just think back to the time when I started putting smarts-to-web and these were the first steps I took, and I looked for that kind of hand holding as I figured out how to make it work. Jay Jacobs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Forking in mod_perl?
I was just going to post that url to the guide also... But another option I've come up with not listed in the guide is to use the *nix "at" command. If I need to run some processor intensive application that doesn't need apache_anything, I'll do a system call to "at" to schedule it to run (usually I pass in "now"). However, the drawbacks are that it's a complete seperate process and passing complicated structures isn't worth the time to think about using at. Jay On Wed, 4 Oct 2000, Geoffrey Young wrote: -Original Message- From: David E. Wheeler [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 04, 2000 3:44 PM To: [EMAIL PROTECTED] Subject: Forking in mod_perl? Hi All, Quick question - can I fork off a process in mod_perl? I've got a piece of code that needs to do a lot of processing that's unrelated to what shows up in the browser. So I'd like to be able to fork the processing off and return data to the browser, letting the forked process handle the extra processing at its leisure. Is this doable? Is forking a good idea in a mod_perl environment? Might there be another way to do it? http://perl.apache.org/guide/performance.html#Forking_and_Executing_Subproce ss the cleanup phase is also a good place to do extended processing. It does tie up the child until the processing finishes, but it at least make the client think that the response is finished (so that little moving thingy in netscape stops moving around) HTH --Geoff TIA for the help! David -- David E. Wheeler Software Engineer Salon Internet ICQ: 15726394 [EMAIL PROTECTED] AIM: dwTheory
RE: Question about $sth-finish;
On Tue, 15 Aug 2000, Tom Mornini wrote: It is my understanding of the DBI docs that you only need to call $sth-finish when you DON'T fetch all the rows that the $sth has ready to return. From "Writing Apache Modules with Perl and C": "You should still call finish() at the end of each series of fetches, even though you are going to reuse the statement handler. Failure to do so can lead to memory leaks." If I remember correctly, it also frees up any resources used by the database (depending on db) for the query, like for sorting, joining, etc. But I can't quote a source for that one. From my point of view, it never hurts to call finish()... Jay Jacobs
Apache::Session Math::Currency thawing issue.
Hello, I'm trying to use Math::currency with sessions, and I've run into a stumper. I initialize variables and make them Math::Currency objects, and display them just fine, but when I come back (unthaw the session) instead of seeing the value I get the reference showing "Math::Currency=HASH(0x86b022)" instead of the value as it showed the first time through. It's a reference going in, and a reference coming out, but for some reason it doesn't like being stuck into Apache::Session. I can work around it by testing if it's a Math::Currency reference, and call Math::Currency-new. But this seems a little silly. Anyone seen this before? Jay Jacobs
Re: Apache::Session Math::Currency thawing issue.
First off, I'm doing this becuase I need to store variables (in currency) that are generated on a per-user session, for a short period of time (3 to 5 requests). I'm using a database back-end for the session. I was initially wrong in my thinking about Math::Currency, and my solution was to "stringify" the instance, so I only store "$10.45" instead of a Math::Currency object. Where do you put your "more permanent" data, and what constitutes "more permanent" data? I can't think of anything that would be faster/easier to store and retrieve specific information related to that user or session. I'd agree that the session needs to be handled carefully, but I think the careful part is not leaving stuff in the session that doesn't need to be there, instead of not using it. Jay On Mon, 19 Jun 2000, Shane Nay wrote: Okay, backup a second..., you're doing this... why? Do you need a Math::Currency object stored inside the session?..., that could be quite a hefty object. See, everything you write to a session you have to read back in, and any time you update any small part of it it has to re-write the whole record. What storage mechanism are you using for sessions, Filestore, Database? Generally I think it's a best practice to be careful about what you're stuff in your sessions, i.e. how much data you're putting in there. A complete update of several objects could be pretty hairy since you have to do a complete re-write of that record whenever you change one small detail. You also have to read in that entire session, and decompose it which could take a little while. Basically you're adding quite a bit of overhead to your web-application. Personally I like to keep my sessions really small, and put more permanent data elsewhere, does anyone else have a "best practices" sort of thing on what should/should not be stored in a session? (This seems to come up almost weekly I think) Thanks, Shane. (Also you should read up on freeze thaw, because they can't store _everything_) On Mon, 19 Jun 2000, you wrote: Hello, I'm trying to use Math::currency with sessions, and I've run into a stumper. I initialize variables and make them Math::Currency objects, and display them just fine, but when I come back (unthaw the session) instead of seeing the value I get the reference showing "Math::Currency=HASH(0x86b022)" instead of the value as it showed the first time through. It's a reference going in, and a reference coming out, but for some reason it doesn't like being stuck into Apache::Session. I can work around it by testing if it's a Math::Currency reference, and call Math::Currency-new. But this seems a little silly. Anyone seen this before? Jay Jacobs
RE: Apache::Session
Mod_Rewrite does the same thing in a few less lines:
RewriteEngine On
RewriteCond /your/document_root/%{REQUEST_FILENAME} !-f
RewriteRule ^/S([^/]+)/(.*)/$2 [E=SESSION_ID:$1]
the RewriteCond statement just makes sure you don't (for some strange
reason) have a file/directory that is of the same name as the request, and
it's completely removable
This also doesn't change the $r-uri value, but I find that kind of a
blessing.
Jay Jacobs
LachNet Inc.
On Thu, 1 Jun 2000, Michael Nachbaur wrote:
Well, from what I'm reading, it looks like you don't want it to create sessions for
all images, CSS, et al on the first page load, right? Instead of deleting sessions
that aren't used, you could try just not serving sessions to documents that don't
need 'em.
Like in my setup, I've put in a PerlTransHandler pointing to a custom perl module
I've created:
PerlTransHandler Apache::URISession
Then, in Apache::URISession, I've done the following:
package Apache::URISession;
use strict;
use Apache::Constants qw(:common);
sub handler {
my $r = shift;
my $uri = $r-uri;
my ($session) = $uri =~ m|/S([0-9a-f]{32})|;
$uri =~ s|/S[0-9a-f]{32}||;
my $filename = $r-document_root . $uri;
$ENV{'SESSION_ID'} = $session if ( $session );
print STDERR "SESSION: " . $session, "\n";
print STDERR "URI: " . $uri, "\n";
$r-uri($uri);
$r-filename( $filename );
return OK;
}
1;
__END__
There might be another module that does this, but I wanted to embed the session key
in the URL. So, in this example, it'll redirect the user to an address like this one:
http://127.0.0.1/S94b419c5908ae5f0773a4bfd61cbec1d/index.html
It'll rip the session out, put it in ENV{SESSION_ID}, and continue processing. I'm
not sure if I should be returning an OK there or not (I'm new to using handlers), but
it does the job.
Also, keep in mind, I'm using the new Apache::Session which creates 32-character
keys, which is why I'm doing the pattern match check like {32}.
-man
-Original Message-
From: Niral Trivedi [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 01, 2000 12:57 PM
To: [EMAIL PROTECTED]
Subject: Apache::Session
All,
I need to clear myself on a small issue regarding Apache::Session.
As per my understanding, Apache::Session will store session information
in a backing store-either a flat file or in some database. And
everytime, request comes in, it will check for sessionID in backing
store and retrieve all information for that session. If request is new
than it will create new sessionID and also create an entry in backing
store..
Now, only way to remove this information from backing store is to do
'tied(%session_hash)-delete', Am I right? I mean is there any way we
can remove these entries by setting 'time_out_interval' or something
like that??
Because if we do 'tied(%session_hash)-delete' then it will create new
session for every request... So, I was thinking of not doing
'tied-delete' but write a small cron script which runs at specified
interval and removes entry from backing store which are older than some
time...
Because concept of 'time_out_interval' does exist in Apache JServ and
other application servers..
Any ideas, suggestions or pointers on this???
Thanks again..
Niral
--
Re: talking about cookies (was: session something...)
The issue isn't the technical aspects of the bug, or even the fact that users don't have to turn off cookies to fix the bug... the issue is that this, with help from the talented press, will cause more people to simply disable cookies whether right or wrong. This ties back into a previous discussion about storing sessions (or session_id) in a cookie and how reliable (or unreliable) that is. Jay Jacobs LachNet Inc. 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? What great functionality is lost if users turn off their scripting? Of course, this may be an abstract question in terms of programming, if users *do* insist on enabling scripting. I do notice that both Microsoft and CERT, in their different ways, recommend that folks turn off scripting for best protection against cross-site scripting attacks: http://www.cert.org/advisories/CA-2000-02.html http://www.microsoft.com/technet/security/crsstQS.asp So maybe some will get the message. Though making ridiculous recommendations like avoiding "promiscuous browsing" (CERT's words) doesn't help. And MS's recommendation simply eliminates E-mail-based attacks using their product (Outlook), while leaving others exposed. They make it ridiculously hard to turn off scripting, then show you how to do it only in a limited way. 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.
Re: [Summation] 100% sessions?
I really liked this solution... here is the simple mod_rewrite stuff I've
stuck into my httpd.conf to pull out the session_id:
RewriteEngine On
RewriteCond /your/doc_root/%{REQUEST_FILENAME} !-f
RewriteRule ^/S=([^/]+)/(.*)/$2 [E=SESSION_ID:$1]
When you set your session_id, be sure to prepend the "S=" to it. I
figured that was a much better solution then just looking for 16
characters, although I put the !-f condition in there to test if it was a
file... by the slim chance that the S={session_id} pattern is actually a
real file... it could be done away with.
After this rewrite rule there will be a $ENV{SESSION_ID} variable set for
use in any application (regular cgi included)
This will also set the $r-filename to not include the session_id which
means that mason and the like won't break down looking for the file.
Note: This does NOT change $r-uri which will still contain the session
stuff in it.
Jay Jacobs
LachNet Inc.
On Thu, 11 May 2000, Gunther Birznieks wrote:
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.
snip
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 lik
Re: [Summation] 100% sessions?
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.
Re: [Summation] 100% sessions?
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. snip 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: A Href="/abcdef123456abcdef/index.html"Home page/a 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.
100% sessions?
I've been perusing the archives on the topic of cookie vs. url vs. user session tracking, and I can't find a solution that is 100% effective. Here's the scenario... using Apache::Session::DBI on a public site, where registered users can log in to get detailed information and "place orders" online. Non-registered users will get basic information and ideally should be able to "place orders" that will have no real effect on the site (i.e. shopping cart with no purchasing) Here's some major concerns I groked from the archives: cookies: disabled from proxies, or disabled for "security" user-based: wouldn't solve non-registered user issue, nor site-wide url: requires site-wide url-rewriting, insecure from HTTP_REFERER standpoint My thought is to try to verify it from ip but that breaks when proxies come from more than one ip (AOL), or when nat is in place covering multiple client systems. Also adding a lame security attempt, and put a timed expiration on the server-side session after an hour or so. I'm thinking of just relying on cookies, while not 100%, it's gotta be close to 80 or 90% which may be good for this project. But I figured others had faced this same issue and had an ample solution... Jay Jacobs LachNet Inc.
Re: 100% sessions?
On Tue, 9 May 2000, Jeffrey W. Baker wrote: Why is the session ID invalid just because they left for a week? Ask them to authenticate again and take them right back to whatever they were doing. On some sites bookmarking the URL with the session ID embedded is the optimal behavior. -jwb Session-jumping is a key concern in my application, once a user logs, they're going to be looking at sensitive information that pertains directly to that user. Sessions need to be timed and expire in a short amount of time (30 mins or so) of inactivity. If a registered user comes back after that time (from a bookmark or refresh), I'm going to redirect them to the login page, and then putting them to the originally requested document after they authenticate, just like you said. I just can't see tying in the ip address, or any other mechanism as being 100% effective for session management... Jay
