RE: Summary: identifiying unique users
Ged wrote: How to avoid multiple logins? The short answer is: you can't. Sure you can. Charge $10 per login. I don't want to clobber the list with non-technical trivia, but even when you charge money, you can't avoid it. If only there is one user that is willing to pay the amount twice, your scheme is broken. As with technical solutions: the higher the amount you charge, the lesser the risk of people doing it. But the risk remains... --Frank
Summary: identifiying unique users
Stas Bekman wrote: Perrin Harkins wrote: Zack Brown wrote: I'd like to implement something that tries to ensure that one user can't masquerade as multiple users. We talked quite a bit about preventing multiple logins recently. I think it was last week. Check the archives. Perhaps someone would like to summarize these and put a short tutorial on perl.apache.org? This question seems to come back pretty often. I tried to recap the discussion and looked in the archive. Am I wrong when I summarize it with it is not possible in a foolproof way? Or, with a bit more words: | How to avoid multiple logins? | | The short answer is: you can't. To ensure that a login is only used | by one person at the same time, you need to have some method to | identify persons. You can't do that based on the information you | can get from a request. And even if you could get information, there | is no guarantee that the information is correct - it can be faked | | IP-address |can hardly be mentioned as a contestor with proxy servers, |firewalls, anonimyzers and the rest; | | MAC-address |there are reports that it is able to get this as part of the UUID |or in an SSL key, but it can't be trusted as a user could simply |change this or make it a non-unique value | | SSL session id |it seems that SSL_SESSION_ID offers some unique recognition of |the client; it stays valid for some time (hours, days) and is |there to avoid needless handshaking | | Cookie |you can do something supplying a unique identifier in a cookie |that you provide, but chances are that you lock up your system. |The interesting issue is 'when do you expire a cookie/user link?' |Do this too early and you will allow logins to hop from one person |to the other, do this too late and you will have problems with |people that (for instance) suffer from a crashing browser | | Where IP and MAC address seem totally unusable, the SSL session and | your own cookie offer a mechanism that can of use. If you aim at the | not-so-technical user and are prepared to be rude to those users | that tamper with your system, you can make it work to some extent. Comments and additions to this summary are welcome through the list. After polishing this, it can be brought into the proper docs. --Frank
RE: Apache::Session permissions problem
I'm afraid that is not a very good article. It's out of date, ... Apache::Session::DBI (which is what the article refers to) is ancient and should not be used. I stumbled upon this problem quite a few times. Trying to get the hang of using cookies for authentication and sessions there are tons of modules and (a bit less...) articles, but they all seem outdated or simply not useful. So I build something myself, but am not quite sure this was the way to go. I had the same experience when (OT, sorry) I looked into things about using XML in combination with (mod_)perl. Most of the articles are rather old and I have no clue if they are outdated. Here as well I made some choices of my own, still thinking I am at least reinventing part of the wheel. Is there a, or are there initiatives to keep an 'accurate' document repository? I personally like perl.apache.org as a starting point, but it is quite restricted to mod_perl and mod_perl alone. (This is not meant as a rude remark!). Should and could this be broader containing links to interesting articles on 'well known subjects'? Should we then need som (continuous) reviewing and rating mechanism to separate the good from the bad? Or is Google still the way to go? --Frank PS: Apache::Session::DBI might be ancient, when I did some research for this mail I stumbled upon http://perl.apache.org/docs/1.0/guide/snippets.html#An_example_of_using_Apac he__Session__DBI_with_cookies. Perhaps it is a good beginning to try to keep/get outdated and ancient stuff from Our Main Source of Information?
Re: Use of uninitialized valued in concatenation....
B. Fongo wrote: Script_name.pl: Use of uninitialized value in concatenation (.) or string at output_tab.pm line 42. Perrin replied: This is a standard perl error message. It is not related to mod_perl. You can look in the perldiag man page for a more complete explanation. B. Fongo wrote: It is not a standard perl error message. I went through mod_perl doc at http://perl.apache.org/docs/general/perl_reference/perl_reference.html#T racing_Warnings_Reports I am sorry, but it *is* a standard Perl error message. It means exactly what it says: you concatenated or stringify an undefined value. Looking in your code (of which I do not know exactly where it starts, so line 42 is a bit of a guess) it can be either print qq(td bgcolor='#d0d0d0'$_/td); or print qq(trtd colspan=$columnspan bgcolor='#d0d0d0'nbsp;/td/tr); In the latter case, please check $columnspan to be sure it is given a defined value. For the first: you go through a list of tablerow values, can it be that a value is NULL? This would be translated into undef and hence raise this warning. Try to replace with my $val=$_||'NULL'; print qq(td bgcolor='0#d0d0d0'$val/td); --Frank -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Re: AW: AW: Use of uninitialized valued in concatenation....
On Sat, Aug 23, 2003 at 01:55:03PM +0200, Marcel Greter wrote: This is not a very good solution. You would also catch the case where $_ is 0, which may should not happen. You would better do Yes... I always fall into that pithole. I think this is because I find the 'defined(...) ? ... : ...' phrase is kinda ugly. Silly me, I know. $_ = defined $_ ? $_ : NULL; Still... I don't know if I like toying around with $_. Especially since you change the real array value (and not a copy) and this might cause problems later on (should you use the values somewhere else as well). But why are we talking about this on a mod_perl list. Sorry guys. --Frank -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: How to restart the root server from within modperl?
On Tue, Aug 12, 2003 at 11:50:01AM +0200, Dirk Lutzebaeck wrote: Dennis Stout writes: On a whim, I would try writing a second script to do the actual shutdown and restart of Apache. Then have your mod_perl program either run it in the background (with a ) or fork it into another process. Did exactly that but is has the effect that when the parent (root) apache is killed it kills all children including the script itself. So the server wont start again. Since you are talking about a management tool via http, you might consider using a second server process for this. If you select the 'restart link' then under water you need to (a) startup a server on a different port, (b) redirect to a URI on that server, (c) make it that that URI restarts the main server as you would normally do, (d) clean up the second server as soon as the main server restarts. You can do this in a sophisticated manner by creating a httpd config on the fly, using a unique restart-URI, thus avoiding the most obvious security risks. Might work... --Frank
RE: unsetting PerlTransHandler
I'm wondering why it is impossible?
I am not exactly sure here, but I think this is because a TransHandler
is definitely not allowed inside a Directory or File container. And
since Apache does not make the distinction between containers (it uses
the constant RSRC_CONF to disallow a directive from being in (all)
containers) Location is the innocent victim here.
For now I have implemented that particular case by
Wouldn't this be simpler?
|PerlTransHandler MyPackage::transhandler
|Location ...
| PerlSetVar SkipTransHandler 1
|/Location
|
|package MyPackage;
|
|sub transhandler {
|...
|return DECLINED if $r-dir_config('SkipTransHandler');
|...
|}
--Frank
Re: unsetting PerlTransHandler
On Thu, Aug 14, 2003 at 11:07:13AM -0400, Geoffrey Young wrote: There is actually a Location/LocationMatch sequence performed just before the name translation phase (where Aliases and DocumentRoots are used to map URLs to filenames). The results of this sequence are completely thrown away after the translation has completed. which is what you found in the code - note the completely thrown away part. in essence, this means that the results of the Location config merging are discarded prior to translation, after which Location merging is done again. Ehm... considering both solutions worked and the quoted paragraph, shouldn't we read it as 'the results of this sequence can be used during the translation phase, but are thrown away after the translation has completed'. This would mean that the results are not discarded prior to translation, but after translation and that would also explain why the two solutions work... --Frank
RE: unsetting PerlTransHandler
and want to unset the TransHandler inside the Location. How to do that? AFAIK: not. The TransHandler is the first to be called and cannot appear inside a container (ref. ModPerl cookbook). The only thing I can think of, and in fact implemented this, to make the TransHandler URI-aware and return immediately if the uri is something you do not want to be touched by the TransHandler. Hope this helps --Frank
RE: How to pass parameters from the UNIX command line ?
http://server.domain.com/cgi-bin/MyProcedure.pl?cust_id=x I'd like to make a cron job to source the above PERL script as from the command line to resemble something like: perl /usr/local/apache/cgi-bin/MyProcedure.plneed to pass the parameter here as cust_id=x I am very doubtful if running a mod_perl script from the commandline would make any sense... There is no Apache:: in that context to name something. You could do something tacky with Apache::FakeRequest, but it's far better to write a proper, not web-tuned, script to do the chore. Or use GET from the commandline with the uri behind it. This makes it a proper request to your webserver, issued from the command- line (or crontab in this case). --Frank
RE: no_cache(1) and still cached?
On Fri, 2003-07-25 at 04:32, Frank Maas wrote: Come to think of it, I have never had problems with mod_proxy caching thing I didn't want cached. Quite the opposite -- I had to be very careful with Expires headers to get anything cached at all. I think you might be mis-diagnosing the problem here. Maybe it's an issue on the backend instead. Well, I thought that too, but couldn't get a grip on it. Picture the situation I described before. Whenever a page is served outside it's template, a logmessage is generated. Now when I see a page without template on my screen (wrong) and I look in the logfile I see that only the allowed address is written as being served. That's why I thought there was some optimisation in the cache engine that limited the number of equal requests to the backend to one for each URI. This would then even go beyond any headers, but more on the principle of 'the page served at exactly the same moment is the same page'...? --Frank PS: I now removed the caching mechanism from the setup and everything is working fine through the proxy. Whenever I cross this bridge again I will start looking more closely.
no_cache(1) and still cached?
Hi, Recently I found some strange behaviour of the caching-functionality of Apache. I had configured one httpd as caching proxy and a second one creating the pages. Two kind of pages are created: dynamic ones (with no_cache(1)) and static ones (with an expiry set to some minutes or hours). What I found was that sometimes users got served 'cached' dynamic pages. Although the server should not cache the page it looked like this happened whenever two requests were received at (nearly) the same time by the server. Has anyone of you experienced this before and does this harm current ideas about caching proxies? --Frank
RE: handler($$) unreliability
Are you using 'lookup_uri' or another form of subrequest somewhere
in your handlers? Try tracing your request and see where it goes
wrong. I had similar problems and it pointed out to be an error in
a subrequest. Consult the mailinglist archive if you want.
--Frank
I have handler that looks like this:
sub handler ($$) {
my ($class, $apache) =3D @_;
Apache::request($apache);
$apache-status(200); # Default
#.
}
The vast majority of the time, this works fine. Every now
and then, usually after the apache server has been up
...
RE: Authentication design
Perrin Harkins wrote (in a discussion with Michael L. Artz): Well, I figured that the AuthenHandler already parsed the authentication cookie and declared it valid, so I didn't really see a point the in doing it at the beginning of every script. $r-user just seemed more intuitive to me. Well, I'm not sure what's involved in determining $r-user aside from reading the cookie. It may not make any difference. Here's a typical pattern for this: [...] The session stuff could be done in a separate phase before the content handler, or it could be done on demand when your script calls some utility method that knows how to get the current session. Same with the user. Isn't this more a matter of 'niceness'? Putting the session/user stuff in AuthenHandler and then setting the $r-user makes it clear where the authentication takes place. All other handlers just check if $r-user is set and need not to bother with sessions and stuff? Or is there something against this and would you be a supporter of having it all in the same handler? --Frank
RE: [ANNOUNCE] Practical mod_perl is out!
well, the (long) wait is now over - Practical mod_perl is here. Geoff, you might be the best person to ask and it might be a worthwhile extension to the mod_perl-documentation: why would one use this new book if (s)he has the mod_perl cookbook already. I am not trying to set a new war between authors here, but wouldn't it be an idea to have such a 'review', giving interested users an idea of what they could buy? On one of my shopping sprees I bought 'Perl in a nutshell' and not that much later the Camel-book, only to find that I can put the nutshell far away as I never read it (sorry author). This experience is holding me back a bit when it is about buying a new book that covers the same subject as another book. Hope you can help us! --Frank
RE: trouble with using $r-lookup_uri()
I'm trying to write a authentication handler using mod_perl, and am encountering some difficulty. I have isolated my problem to the usage of the lookup_uri($uri) function call - whenever I call it, my module segfaults. I have tested the input with both a variable string, and just a quoted string, and get the same result. I don't know whether this will help you, but don't just focus on this handler. I encountered problems using lookup_uri myself, because I did not bear in mind that -lookup_uri goes through a request cycle itself, thus calling a far lot of the handlers defined for that uri. However it is not a complete request, so things like -pnotes etc. can fail. See http://marc.theaimsgroup.com/?l=apache-modperlm=105118150200822w=2 for my 'diary'. --Frank
RE: stopping concurrent logins
On Fri, Apr 04, 2003 at 03:34:25PM +0200, Frank Maas wrote: You can set a session (see Apache::Session and related modules) that can use the uri as session-container as well (eg http://www.example.com/9o79876a98d7fa98d7/path/to/doc). The session part (9o79876a98d7fa98d7) can be stored in a database. Success. Technically, that doesn't solve the problem either. Since the session information is in the URL, there is nothing to stop the user from IM that URL to their friend, who then has total access, without a cookie, just by using the current users session. I must not fully understand the taboo against using cookies. It's rare that an online application, e-commerce related or otherwise, works without cookies. If you're doing anything more than browsing static data, you'll quickly become fustrated at the lack of support for non-cookie-enabled browers. On the latter I totally agree. To avoid the session snatching you describe, you can store IP addresses on your site in the database. You won't solve proxyserver-problems with this though. So what about the following approach: * a user logs on and you issue a session, as part of the uri * when the user requests another page, you fetch the session from the uri, check it against your database and (let's assume it's correct) you allow access but while issueing a new session If this works (and as some people consequently add 'untested') then session snatching becomes a hell of a job. If one user logs in, and the other copies the session and retrieves a page, the session changes, so the first user has to copy the new session again. Sounds promising But to return to my first phrase: with cookies it's much more simple. --Frank PS: What I never got though... how 'bout stealing cookies from someones system?
RE: stopping concurrent logins
On Fri, Apr 04, 2003 at 10:13:59PM +0200, Frank Maas wrote: On the latter I totally agree. To avoid the session snatching you describe, you can store IP addresses on your site in the database. You won't solve proxyserver-problems with this though. So what about the following approach: * a user logs on and you issue a session, as part of the uri * when the user requests another page, you fetch the session from the uri, check it against your database and (let's assume it's correct) you allow access but while issueing a new session Interesting idea. I assume that you're keeping the session key/ID in the URL, right? Does it break if someone hits back (and goes to a page that's full of URLs with on old session ID in them) and then clicks on one of them? Yep. I think that the back-button is out of the question in such a solution. Of course one could think of yet another scheme that makes it possible to use the back-button. But a more simple solution is to create a back-link on the page. --Frank
RE: AuthDBI logoff
Hi Todd, Trying to logoff using Basic Auth is becoming something of a faq... if there was a means by which i could strip out the Authorization header in the client request, this would force a 401 response from the server which would also satisfy my specific need. I doubt if this will work. I suspect you want to strip this out when the user does his logout-request (ie. a request for .../logout.html). If you do this, the browser should present a popup-box to the user, which he most probably would cancel. However, most browsers seem to recollect their authorisation information they used before. Thus, as soon as the user gets to a page that requests a login, the browser tries with the user credentials that were kept and a popup is never shown. As someone already suggested: use a Cookie based algorithem. The cookie gives you the opportunity to follow the status of the user and effectively log him out. Another approach I once saw was the use of a dedicated realm for that user. In stead of using a fixed realm (ie. security domain) the domain is on a per session basis. You should still fix the session someway (using the uri or a cookie), but you can still stick with the 'Basic Auth' mechanism. Hope this helps. --Frank
RE: binary cgi mess ( repost )
Comparing your post and that of others, I see that you use Authentication through mod_perl. What happens if you completely disable Authentification? Do you still experience the same problem? --Frank
error using instance: can't locate ... pnotes .. via
Hi, I am workin on a site where all pages are handled via an Apache::SSI descendant. Some included parts are itself mod_perl routines that use the instance-methode to recreate the request. The routines work fine if used standalone but as soon as the routine gets included via the SSI method (subrequest?) apache/mod_perl complains. The call to instance results in an error 'can't locate method 'pnotes' via package X::Y::Z', where X::Y::Z my own package is. Most probably the error is in me, can you help me point it out... --Frank
RE: Basic Auth logout
this has been asked before, and I've found in the archives there is no way I could have a logout page for the Basic Auth in apache. Is there nothing I can do ? This is required only for the development team, so we need to let mozilla or IE forget about the username and password. And would this be possible with mod_perl2 ? What you could try (note the 'could', it's not tested) is return a redirect to the same realm with a different id/password that is not correct. If your site is www.mysite.com then redirect to http://logged:[EMAIL PROTECTED]/ This might help as browsers can interpret the popup this will trigger (as user logged with pass out is not known) as an implicit logout). Good luck. --Frank
RE: error using instance: can't locate ... pnotes .. via
Regarding my previous post: ... The routines work fine if used standalone but as soon as the routine gets included via the SSI method (subrequest?) apache/mod_perl complains. The call to instance results in an error 'can't locate method 'pnotes' via package X::Y::Z', where X::Y::Z my own package is. It seems as if the handler is called as if it were a method handler...? But it's not defined as such (from the Cookbook: ...the trigger for mod_perl is the use of the prototype ($$)). Huh? --Frank
What does SetHandler do unexpectedly?
Hi, Well, by now you must know that I am working on something... and I keep stumbling on things I seem not to understand and not to be able to find in the docs / books. See this example: Location / # SetHandler perl-script PerlHeaderparserHandler MyClass-first PerlAuthenHandler MyAuthen PerlFixupHandler MyClass-init # PerlHandler MyClass-handler PerlCleanupHandler MyClass-last /Location I have stripped almost all functionality and just let the subroutines print. With this setup and a 'get http://mysite/dir/file' I see: -- first: got /dir/file authen: called for /dir/file init: called for /dir/file [error] ... /dir/file not found -- last: finished /dir/file No strange things, what I would expect. But now I remove the comments and see what happens: -- first: got /dir/file authen: called for /dir/file init: called for /dir/file authen: called for /file init: called for /file handler: called for /dir/file [error] ... /dir/file not found -- last: finished /dir/file What strike me are the two lines for /file. Why is this happening? I did not ask for it, at least not deliberately. Is this something that is related to a Handler (check one level below the uri)? Hope you can help me here (and on the other subjects...) --Frank
RE: Apache dies when configure mod_perl for use with Apache::DBI
This is the only error line that appears in the error_log. [Sun Mar 2 20:10:19 2003] [notice] caught SIGTERM, shutting down Perhaps it's me, but could you please create a copy-n-paste mail with the (correct) relevant code snippets (httpd.conf, startup.pl, etc.). This might help. Best regards, Frank
How to avoid loss of POST data in a good way?
Hi, Excuse me for this question that is, without question, due to my newbie- ness, but I am against a wall here. I am creating a website that is running under mod_perl and using several handlers of the chain. The website uses the POST method to send form data. I first used Apache::Request-new() in all handlers, but that made that I lost the posted data after its first use. OK, this was somewhere in the manuals and books and I changed to instance(). My problem begins when I use CPAN or other already-made modules that seem not to respect this and again the posted data got lost. What is the best solution to avoid this? Another question is: why does new() not do what instance() does in the first place? Another solution would be that the posted data is read once and then silently put on a stack so a next call in the same request-cycle can reuse it? Related to this issue... (and as newbie as the above): I seem not to be able to find the connecting two phrases when it is about combining mod_perl and CGI.pm. CGI.pm is (amongst others) all about reading formdata, persis- tance and creating webpages. For this it has to read the request. How does this interfere with my own actions for getting to that information? To combine all of this in an example application (and I am sorry if it is really bad): --PerlAuthenHandler--PerlHandler--PerlLogHandler- | - retrieve some cookie - retrieve some form param's - use CGI.pm - retrieve some form param's - retrieve some form param's Any help is appreciated, even if you flame me to a location where I can (really...) find this. --Frank
