Using Perl to find what address bar says

[Keith Keller]

Sure.

My point, I guess, is that the original poster was flamed to a
crisp for allegedly not knowing what he's talking about when he
asked how Perl code on the server side can find out what's in the
client's address bar.

Your "Perhaps" seems to imply that it's not obvious that what the
OP was asking about is impossible.

The OP first asked how to do this "in Perl", which already implied that
he didn't understand the concept of web applications; then, when he
resigned to do it in AJAX, complained that "Perl is dying every day",
thus turning his own misunderstanding of client-server communication
into an indictment of Perl. I'm pretty sure it's this latter that got
him flamed. (I'm also not sure how the OP thinks that someone using an
anonymizer won't be wise to short-circuit AJAX communication as well,
but I can imagine someone being told to install the anonymizer but not
that AJAX may or may not circumvent it.)

--keith

 

[Ben Goldberg]

I admit that *I* don't have a very clear understanding of how
web apps work, so the following is likely to be completely wrong.
I'd be interested in knowing what's wrong about it.

Perl generally runs on the server side, and therefore doesn't
have access to the browser's (client's) internal information (in
this case, the contents of the address bar).  Javascript generally
runs on the client side: the browser downloads Javascript code and
executes it locally.  Have I got that right so far?

Would it be possible for some Javascript code, running in the
browser, to query the contents of the address bar and then send
that information to code running on the server?

My first thought is that this could open up serious security holes,
and that there are measures already in place to prevent it, but I
don't know the details.

By the time the javascript code has been downloaded by the browser,
the url will have changed!

That is, the user starts out viewing page A, and the url for A is in
his browser's address bar.

Page A has a link to the CGI script, B.

The user clicks on the link.

The new page (with javascript in it) comes back to the browser. But
the browser's address bar now shows the url for B.

The url of the prior page (A) may not be accessible to the JS Script,
because browsers often limit what scripts can see for security
purposes.

Thus, the JavaScript only knows that the address bar *now* is B. Even
then, it might not know that, if the script has been filtered so that
it doesn't see the real variables. For example, normally a page's
location is available in via the javascript variable location.href,
but location might be replaced with a different object, whose .href
field contains a different url. With a good quality web anonymizer,
this might be done to improve transparency. Of course, they might
take the easy way out, and strip out any javascript entirely!

The client side javascript script can activate the browser's "back"
functionality (using history.back(), or history.go(-1)), but often
(for reasons mentioned above) won't see anything in the
history.previous field.

Similarly, if the browser hasn't sent the url of A to the web server,
then the server won't pass A's url in via the HTTP_REFERER environment
variable. For that matter, if the user is using an anonymiser, you
can be absolutely positive that it won't send in url A as the referrer
-- it might send nothing, or might make up some random garbage. You
also won't get a referrer if url A was an https page. You also won't
get a referrer if your page was typed into the url bar of the browser
directly. You also won't get a referrer if your page was bookmarked,
and accessed via that bookmark. You also won't get a referrer if
someone made your page their browser's home page, and they clicked
home. You also won't get a referrer if your page is accessed by a web
crawler. Etc, etc,.

Hardly any of this has anything to do with Perl, of course.

 

[jwcarlton]

Can you guys think of a way, in Perl, to find what the address bar
actually says? I don't think that $ENV{'SCRIPT_NAME'} is quite the
same, because it's only going to show me what it's SUPPOSED to be.

I'm trying to find if a user is using something like anonymizer.com or
hidemyass.com, and it seems like the easiest method is to compare
$ENV{'SCRIPT_NAME'} to the address bar. I can do it in Javascript, but
I'm hoping there's a way to do it in Perl.

In spite of the "genius" replies saying that this is impossible and
that I'm an idiot for asking, for future readers, there IS a way to
find if a user is using something like anonymizer.com or hidemyass.com
using Perl.

First, upload phpinfo.php (I know, that's PHP. Whatever. You can do it
in Perl if it suits your fancy):

<?php
phpinfo();
phpinfo(INFO_MODULES);
?>

Now, load this normally in your browser, then load it again using
hidemyass.com, or whatever other proxy you want.

Doing a side-by-side comparison, you'll see several discrepancies. The
most notable on my end is that hidemyass.com didn't recognize Session
Handling; so, I can simply load a session variable on one page, then
test for that variable on the next page. If it doesn't exist, then
they're probably using a proxy.

It's not perfect, since browsers with cookies disabled probably
wouldn't recognize sessions, either. But since my site would be
virtually unusable without cookies, I'm not so concerned about that.

If that won't work for you, another discrepancy found was that on a
normal load, HTTP_CONNECTION is set to "Keep-Alive"; but, using
proxies, it's not set. So, a simple check for $ENV{HTTP_CONNECTION}
might be all that's needed.

There were several discrepancies, though, so using this method you can
pick and choose what's different on your server.

Please don't bother replying to this thread, as I don't intend to
return. My email address is here, though, so feel free to email
questions.

TIMTOWTDI,

Jason

 

[Randal L. Schwartz]

jwcarlton> If that won't work for you, another discrepancy found was that on a
jwcarlton> normal load, HTTP_CONNECTION is set to "Keep-Alive"; but, using
jwcarlton> proxies, it's not set. So, a simple check for $ENV{HTTP_CONNECTION}
jwcarlton> might be all that's needed.

But for those of you who actually want to learn something, there *are*
legitimate proxies that would be indistinguishable using these
techniques. So it doesn't matter that you compare proxied vs not, and
test for that. You'll break legit users.

It's too bad the original poster was so closed minded. {Sigh}

print "Just another Perl hacker,"; # the original

 

[Ted Zlatanov]

jwcarlton> If that won't work for you, another discrepancy found was that on a
jwcarlton> normal load, HTTP_CONNECTION is set to "Keep-Alive"; but, using
jwcarlton> proxies, it's not set. So, a simple check for $ENV{HTTP_CONNECTION}
jwcarlton> might be all that's needed.

RLS> But for those of you who actually want to learn something, there *are*
RLS> legitimate proxies that would be indistinguishable using these
RLS> techniques. So it doesn't matter that you compare proxied vs not, and
RLS> test for that. You'll break legit users.

RLS> It's too bad the original poster was so closed minded. {Sigh}

For his stated purpose (some specific proxies) and the vast majority of
visitors his approach would work. Sometimes there's no perfect solution
and we have to settle for less; I think a real-world conversation would
have reached that conclusion quickly and without the animosity this
thread inspired in everyone.

Ted