Re: Changing browser URL based on condition
Much better to go with a more RESTful approach - the URL is the identifier
for the page and you don't want that identifier to represent the wrong page,
e.g. if example.com/login sometimes returns the home page and sometimes
returns some other page (assuming you can login from and return to multiple
pages.)
Make it so that your home page (or any page) have a login form (or link
which expands to a login form) which POSTs to the login page (or to think of
it in a RESTful way, PUT to a "sessions" URL, thus defining the idea of
"create a new session" - except that browser forms have problems with PUT).
Then from the login page do a redirect to whatever was the referer.
On Mon, Jul 11, 2011 at 12:14 PM, Jerry Pereira wrote:
> Hi Edward,
>
> I have the following design:
>
> A single PerlResponseHandler for all requests. This handler based on the
> path decides the action to be taken
>
> For example, if the user submits to www.example.com/login, then the
> handler delegates the request to authentication module, which will then
> either display the home page (throug home page template) or login page
> again, based on the success/failure of authentication mechanism. Since i am
> rendering the page via template, i am able to generate the content of home
> page which i then send back to the client, but the URL on the browser
> remails the same (i.e. www.example.com/login), which is not true. Any
> suggestions to handle this scenario will be great.
>
> Thanks,
> Jerry
>
> On Mon, Jul 11, 2011 at 12:03 PM, Szekeres, Edward <
> edward.szeke...@perkinelmer.com> wrote:
>
>> If you are looking to do this for “cosmetic reasons”, I do this be
>> simply using frame sets and doing redirects in the child frame. The URL
>> displayed in the location bar will always be constant for the parent frame.
>> I don’t think there is any way to do this at the core level or it would be a
>> spoofers windfall. The browser will always have the actual location in the
>> info panel.
>>
>> ** **
>>
>> *From:* Jerry Pereira [mailto:online.je...@gmail.com]
>> *Sent:* Monday, July 11, 2011 2:48 PM
>> *To:* modperl@perl.apache.org
>> *Subject:* Changing browser URL based on condition
>>
>> ** **
>>
>> Hi All,
>>
>> I would like to know if there is a way to change the URL displayed on
>> browser without using Redirect option. The URL visible on client browser
>> must be based on some condition that is evaluated in my mod_perl handler.
>>
>>
>> For example -
>>
>> 1. User types the URL - www.example.com, this will display the login
>> page.
>> 2. Once the user enters the credentials and hits submit, the request is
>> posted to www.example.com/login action.
>> 3. If the credentials entered by the user is valid then i would like to
>> show
>> the home page..uri
>> 4. I am able to show the homw page, but the URL does not change to
>> www.example.com/home, instead it remains the same (i.e.
>> www.example.com/login). I am using Template toolkit to render my pages. I
>> tried $req->url('/home'), but that does not change the browser URI.
>>
>> Any help will be appreciated.
>>
>>
>> Thanks,
>> Jerry
>>
>
>
>
> --
> Your clothes may be the latest in style but you aint completely dressed
> until you wear a smile!
> Keep smiling : )
>
[no subject]
Re: request length global variable
I've struggled with wanting to use globals too, but it's not the functional
way. Our current approach is to create a parallel request object and pass
that through all of the function calls. We set a member of the parallel
request object to the actual Apache request object. Something like this:
$s->new Session($r, $dbh);
and then in Session,
sub new {
($class, $self->{REQUEST}, $self->{DBH})=...@_;
and then later
DoStuffWithRequest($s);
It might be neater to just override the Apache request object.
On Fri, Apr 23, 2010 at 2:20 PM, Tosh Cooey wrote:
> I'm drawing a blank here and I probably shouldn't be, but...
>
> I would like to use a global variable that's only available for the
> duration of a request.
>
> I guess I could create() and undef() the variable at the start and end of
> each request but that seems so... inelegant...
>
> Any suggestions?
>
> Danke!
>
> Tosh
>
> --
> McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/
>
Re: Usefulness of $r->notes and $r->pnotes (or $c)
We use the notes table to put a reference to the session (and thus the user)
in the access log.
$request->notes->set('session' => $session->{SESSION});
This is in apache2.conf:
LogFormat "%v:%p %h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-Agent}i\" %{session}n" combined_with_session
This makes it possible to differentiate log entries by user, whether
multiple users have the same ip address or if a user's address changes.
On Tue, Mar 23, 2010 at 4:28 PM, Michael Ludwig wrote:
> Let me bore you some more.
>
> First, ModPerl::MethodLookup::lookup_method( $symbol ) is a really great
> help for exploring the API!
>
> m...@colinux:~ > perl aplkp.pl notes
> There is more than one class with method 'notes'
> try one of:
>use Apache2::RequestRec ();
>use Apache2::Connection ();
>
> m...@colinux:~ > perl aplkp.pl pnotes
> There is more than one class with method 'pnotes'
> try one of:
>use Apache2::RequestUtil ();
>use Apache2::ConnectionUtil ();
>
> Good. Now to the point. We have ->notes and ->pnotes on the request and
> connection objects. I've passed some information from mod_perl on to
> mod_php5 using the notes table. Cool. I could pass complex data from one
> mod_perl handler to the other using the pnotes table. Also cool.
>
> It's all in-process, which is cool. It's all per-request (or, if you
> want, per-connection), which sets the scope of its usefulness.
>
> The notes are an APR::Table, the pnotes are a HASH.
>
> What real-life uses have you found for these notes and pnotes?
>
> What could be done at the connection level? Or is this rather too
> low-level for run-of-the-mill web applications?
>
> This is by curiosity and to get my imagination going.
> --
> Michael Ludwig
>
Re: SetHandler perl-script not working
Is that rewrite rule (~line 101) turning everything into an index.php? Sent from my gPhone On Jan 13, 2010 11:02 AM, "Perrin Harkins" wrote: On Wed, Jan 13, 2010 at 7:28 AM, Kevin Thorpe wrote: > I tried stripping everything out as suggested and ended up with only the > basic httpd.conf and pe... There's still a ton of stuff in there. You need to take all of the Files, Location, and Directory stuff out to find the culprit. My wild guess is that if you move this block to the bottom, it will work. - Perrin
Re: adding session id to entries in access log
Thanks! That's a good idea. Just as an example, here are several IPs that seemed to be the same client. The user agent, referer, etc. were all the same and the IPs resolve to the same top-level domain. 205.228.12.236 205.228.12.151 205.228.12.254 On Mon, Oct 12, 2009 at 5:52 PM, Paul Silevitch wrote: > Also, requests that go through a proxy can appear to come from different IP > addresses from hit to hit (or visit to visit). Usually, proxies will put > the real IP as the first IP in the X-Forwarded-For header. > > HTH, > > Paul > > > On Mon, Oct 12, 2009 at 6:43 PM, Douglas Sims wrote: > >> >> We're starting to get some data now and I'm seeing a few minor problems >> with the implementation of the idea. >> >> Here's one: if a request arrives with a cookie that is associated with a >> different IP address then we create a new session entry and send a new >> cookie. I'm noticing that some users have IP addreses that change very >> frequently. This seems particularly likely with mobile devices. We're >> going to have to tweak the algorithm a bit to track activity across those >> requests - or use some attribute of the IP address instead of just the IP >> address - to trigger rotation of the session identity. >> >> >> >> >> >> >> On Sun, Oct 11, 2009 at 10:19 AM, Randal L. Schwartz < >> mer...@stonehenge.com> wrote: >> >>> >>>>> "Douglas" == Douglas Sims writes: >>> >>> Douglas> I've tried to follow the philosophy that Randal Schwartz >>> described in >>> Douglas> a recent thread here - a cookie is just a serial number for a >>> Douglas> browser. By rotating the cookies often we're hoping to avoid >>> Douglas> problems with stolen or leaked sessions and by storing the >>> previous >>> Douglas> session id (if there is one) with every new session we're >>> planning to >>> Douglas> be able to build a linked list of session activity which we can >>> Douglas> correlate with specific users who log in at any part of that >>> linked >>> Douglas> list. >>> >>> That's an interesting idea... brand the browser, but rotate it from time >>> to >>> time, maintaining a list. Thanks for suggesting that... I'll have to >>> explore >>> that in some future project. >>> >>> -- >>> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 >>> 0095 >>> http://www.stonehenge.com/merlyn/> >>> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. >>> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside >>> discussion >>> >> >> >
Re: adding session id to entries in access log
We're starting to get some data now and I'm seeing a few minor problems with the implementation of the idea. Here's one: if a request arrives with a cookie that is associated with a different IP address then we create a new session entry and send a new cookie. I'm noticing that some users have IP addreses that change very frequently. This seems particularly likely with mobile devices. We're going to have to tweak the algorithm a bit to track activity across those requests - or use some attribute of the IP address instead of just the IP address - to trigger rotation of the session identity. On Sun, Oct 11, 2009 at 10:19 AM, Randal L. Schwartz wrote: > >>>>> "Douglas" == Douglas Sims writes: > > Douglas> I've tried to follow the philosophy that Randal Schwartz described > in > Douglas> a recent thread here - a cookie is just a serial number for a > Douglas> browser. By rotating the cookies often we're hoping to avoid > Douglas> problems with stolen or leaked sessions and by storing the > previous > Douglas> session id (if there is one) with every new session we're planning > to > Douglas> be able to build a linked list of session activity which we can > Douglas> correlate with specific users who log in at any part of that > linked > Douglas> list. > > That's an interesting idea... brand the browser, but rotate it from time to > time, maintaining a list. Thanks for suggesting that... I'll have to > explore > that in some future project. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.vox.com/ for Smalltalk and Seaside > discussion >
Re: adding session id to entries in access log
Thanks, Paul and Cosimo.
That module is just what I was looking for. Logging the note instead of the
cookie is probably better for what we're doing.
On Fri, Oct 2, 2009 at 6:56 AM, Paul Silevitch wrote:
> You can use apache's custom log (
> http://httpd.apache.org/docs/2.0/mod/mod_log_config.html) to log cookie
> values into the access logs:
>
> %...{Foobar}C The contents of cookie Foobar in the request sent to the
> server.
>
> The above will not log a value for the first request by a new visitor
> (since the cookie hasn't been set yet). Instead, create a note that gets
> set on every request in your handler and log that:
>
> %...{Foobar}n The contents of note Foobar from another module.
>
> HTH,
>
> Paul
>
>
>
> On Fri, Oct 2, 2009 at 2:21 AM, Douglas Sims wrote:
>
>>
>> We've just launched the first mod_perl site I've ever designed. It's all
>> going very well so far but I'm sure there are some things worth improving.
>> I wonder if anyone might have suggestions about this scenario:
>>
>> I want to add the session id to the access log entries. This example:
>> http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlLogHandlershows
>> how to write to a different logfile but I want to write to whatever
>> would be the normal access log for whatever VirtualHost it's in. We've
>> only got a PerlResponseHandler now but I think this should probably go in a
>> PerlLogHander. What's the best way to go about this?
>>
>> We're very interested in tracking long-term user browsing behavior and so
>> we set one persistent cookie with a session key at each request if there's
>> no cookie or if the existing cookie is obsolete (user logged in, logged out,
>> more than 1 hour since last access, 12 since last visit, IP changed, or user
>> agent changed.) If, when a new session id is created there is an existing
>> (but obsolete) session cookie then the obsolete one is stored in the
>> sessions table as the previous session key.
>>
>> I've tried to follow the philosophy that Randal Schwartz described in a
>> recent thread here - a cookie is just a serial number for a browser. By
>> rotating the cookies often we're hoping to avoid problems with stolen or
>> leaked sessions and by storing the previous session id (if there is one)
>> with every new session we're planning to be able to build a linked list of
>> session activity which we can correlate with specific users who log in at
>> any part of that linked list.
>>
>>
>>
>>
>
adding session id to entries in access log
We've just launched the first mod_perl site I've ever designed. It's all going very well so far but I'm sure there are some things worth improving. I wonder if anyone might have suggestions about this scenario: I want to add the session id to the access log entries. This example: http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlLogHandler shows how to write to a different logfile but I want to write to whatever would be the normal access log for whatever VirtualHost it's in. We've only got a PerlResponseHandler now but I think this should probably go in a PerlLogHander. What's the best way to go about this? We're very interested in tracking long-term user browsing behavior and so we set one persistent cookie with a session key at each request if there's no cookie or if the existing cookie is obsolete (user logged in, logged out, more than 1 hour since last access, 12 since last visit, IP changed, or user agent changed.) If, when a new session id is created there is an existing (but obsolete) session cookie then the obsolete one is stored in the sessions table as the previous session key. I've tried to follow the philosophy that Randal Schwartz described in a recent thread here - a cookie is just a serial number for a browser. By rotating the cookies often we're hoping to avoid problems with stolen or leaked sessions and by storing the previous session id (if there is one) with every new session we're planning to be able to build a linked list of session activity which we can correlate with specific users who log in at any part of that linked list.
Re: Ways to scale a mod_perl site
I'm curious... what is the hardware like on the one server? How many CPUs and RAM? Also, a few thoughts... - You do a 301 from algebra.com to www.algebra.com. That doesn't take much work from the server, but why not just serve up everything from the original location? - The algebra problem I just tried returned twelve separate images. What if, instead of serving gifs you displayed each stage of transformation of the equation using HTML and CSS? That would be rather tricky with things like root signs but I think it could be done - though a bit of work. I wish this site had been around when I was in high school. On Wed, Sep 16, 2009 at 11:48 AM, Adam Prime wrote: > Igor Chudov wrote: > >> >> >> On Wed, Sep 16, 2009 at 11:05 AM, Michael Peters >> > mpet...@plusthree.com>> wrote: >> >>On 09/16/2009 11:49 AM, Igor Chudov wrote: >> >>1) Use a load balancer like perlbal (I am already doing that) >> >> >>A load balancer is good but so are proxies. If you can separate your >>application server from the server that servers static content then >>you'll get a boost even if they are on the same machine. >> >> >> I have very little static content. Even images are generated. My site >> generates images of math formulae such as (x-1)/(x+1) on the fly., >> > > I can understand generating them on the fly for flexibility reasons, but > I'd cache them, and serve them statically after that, rather than regenerate > the images on every single request. You can accomplish that in the app > itself, or just by throwing a caching proxy in front of it (maybe you're > already doing this with perlbal) > > Adam >
Confusion over Apache2::Request and Apache2::RequestRec
I'm confused about something and I wonder if anyone can help me to
understand what's going on. The code shown below works fine but as I was
looking over this before changing something else I realized that it probably
shouldn't. I'm using an Apache2::Request object to return a connection
object to get the remote_ip but the documentation for Apache2::Request
doesn't show a connection method - that's in Apache2::RequestRec.
Why does connection() work on an Apache2::Request object?
Thanks!
-Doug
Apache2::Request:
http://httpd.apache.org/apreq/docs/libapreq2/group__apreq__xs__request.html
Apache2::RequestRec:
http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_connection_
In the PerlResponseHandler:
my $requestrec = shift if $ENV{MOD_PERL};
my $request = Apache2::Request->new($requestrec);
my $session = Sessions->new($request, $mysql);
{package Sessions;
sub new {
my $class=shift;
my $self={};
bless ($self, $class);
$self->{REQUEST}=shift;
$self->{DBH}=shift;
{...snip...}
$self->{DBH}->do('INSERT INTO failedloginattempts (username,
password, ip, session, attempttime) VALUES
('.$self->{DBH}->quote($username).','.$self->{DBH}->quote($password).',
INET_ATON('.$self->{DBH}->quote(*$self->{REQUEST}->connection()->remote_ip*).'),
'.$self->{DBH}->quote($self->{SESSION}).', NOW())');
