History

[Dan]

Is there a way to obtain the last page visited? I don't want to go to
that page, I just want to be able find out what page they came from,
the url of that page. Is this possible?

[Randy Webb]

Dan said the following on 12/3/2005 9:02 PM:

Is there a way to obtain the last page visited? I don't want to go to
that page, I just want to be able find out what page they came from,
the url of that page. Is this possible?

No. And thankfully so. You can try document.referrer but it won't
always tell you what page they came from.

Why do you want to know where I came from?

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Evertjan.]

Dan wrote on 04 dec 2005 in comp.lang.javascript:

Is there a way to obtain the last page visited? I don't want to go to
that page, I just want to be able find out what page they came from,
the url of that page. Is this possible?

Sure, if it is from the same domain, you can use serverside code.

No, if it is from an other site and not referred,
the page has no right to know securitywize.

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

[Etienne Marais]

Randy Webb wrote:

Dan said the following on 12/3/2005 9:02 PM:

Is there a way to obtain the last page visited? I don't want to go to
that page, I just want to be able find out what page they came from,
the url of that page. Is this possible?

No. And thankfully so. You can try document.referrer but it won't
always tell you what page they came from.

Why do you want to know where I came from?

Found this:
(http://www.samspublishing.com/librar...urs&seqNum=100)

////// COPY & PASTE :

The history object is another child (property) of the window object. This
object holds information about the URLs that have been visited before and
after the current one, and it includes methods to go to previous or next
locations.

The history object has one property you can access:

* history.length keeps track of the length of the history list—in other
words, the number of different locations that the user has visited.

Note

The history object has current, previous, and next properties that
store URLs of documents in the history list. However, for security reasons,
these objects are not normally accessible in today's browsers.

The history object has three methods you can use to move through the history
list:

* history.go() opens a URL from the history list. To use this method,
specify a positive or negative number in parentheses. For example,
history.go(-2) is equivalent to pressing the Back button twice.
* history.back()loads the previous URL in the history list—equivalent to
pressing the Back button.
* history.forward()loads the next URL in the history list, if available.
This is equivalent to pressing the Forward button.

//// END PASTE
--
Etienne Marais
Cosmic Link
South Africa

[Randy Webb]

Etienne Marais said the following on 12/4/2005 5:36 AM:

Randy Webb wrote:

Dan said the following on 12/3/2005 9:02 PM:

Is there a way to obtain the last page visited? I don't want to go to
that page, I just want to be able find out what page they came from,
the url of that page. Is this possible?

No. And thankfully so. You can try document.referrer but it won't
always tell you what page they came from.

Why do you want to know where I came from?

Found this:
(http://www.samspublishing.com/librar...urs&seqNum=100)

Forget you found it.
////// COPY & PASTE :

The history object is another child (property) of the window object. This
object holds information about the URLs that have been visited before and
after the current one, and it includes methods to go to previous or next
locations.
But it does not tell you where you are in that list.
The history object has one property you can access:

* history.length keeps track of the length of the history list—in other
words, the number of different locations that the user has visited.
But it will not tell you if the page has previous or next entries. Only
how many are in that list.
Note

The history object has current, previous, and next properties that
store URLs of documents in the history list. However, for security reasons,
these objects are not normally accessible in today's browsers.
Pay close attention to the above as it says exactly what I said.
The history object has three methods you can use to move through the history
list:

* history.go() opens a URL from the history list. To use this method,
specify a positive or negative number in parentheses. For example,
history.go(-2) is equivalent to pressing the Back button twice.
Only if there are 2 pages to go back to. And you have no way of
detecting that using script.
* history.back()loads the previous URL in the history list—equivalent to
pressing the Back button.
Only if there is a page to go back to.
* history.forward()loads the next URL in the history list, if available.
This is equivalent to pressing the Forward button.

Finally, it says they work "if available". Again, forget you found that
site and find a better one.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Etienne Marais]

Drop your bloody attitude,
I know exactly what has
been said on this thread
and have read my own posting
in detail.

I posted this for informational
purposes, what the f*cking hell
is it with all this fighting and
delusional sense of mastery of
subject.

I was not countering your statements,
merely adding what in what I considered
to be an objective manner.

Bugger off Randy

Randy Webb wrote:

Forget you found it.
But it does not tell you where you are in that list.
But it will not tell you if the page has previous or next entries. Only
how many are in that list.
Pay close attention to the above as it says exactly what I said.
Only if there are 2 pages to go back to. And you have no way of
detecting that using script.
Only if there is a page to go back to.
Finally, it says they work "if available". Again, forget you found that
site and find a better one.

--
Etienne Marais
Cosmic Link
South Africa

[Randy Webb]

Etienne Marais said the following on 12/6/2005 1:02 AM:

Drop your bloody attitude,
I know exactly what has
been said on this thread
and have read my own posting
in detail.
Me? Attitude? Welcome to Usenet.
I posted this for informational
purposes, what the f*cking hell
is it with all this fighting and
delusional sense of mastery of
subject.
It has nothing to do with "mastery" of anything. It has to do with what
this group is about - discussion. If you don't want your
thoughts/contributions discussed then you need to find a new medium to
post your thoughts.

As for "informational" purposes, if it is informationally incorrect
(which that article is) then it is open to be rebuffed, which it was.
I was not countering your statements,
merely adding what in what I considered
to be an objective manner.
And it turns out that your reference was next to useless, incorrect, and
had nothing of value in it.
Bugger off Randy

Now, you bugger off.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

[Etienne Marais]

> And it turns out that your reference was next to useless, incorrect, and

had nothing of value in it.

What about it was incorrect ?
--
Etienne Marais
Cosmic Link
South Africa

[Randy Webb]

Etienne Marais said the following on 12/6/2005 7:22 AM:

And it turns out that your reference was next to useless, incorrect, and
had nothing of value in it.

What about it was incorrect ?

Did you read my first reply to your post with the URL? The one where you
copy/pasted from the site and I replied to it, nearly line by line,
telling what was wrong with it and how it didn't help the OP? There is a
lot wrong with the information on that site.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[VK]

Dan wrote:

Is there a way to obtain the last page visited? I don't want to go to
that page, I just want to be able find out what page they came from,
the url of that page. Is this possible?

1) If user came to the current page by clicking a link on the previous
page (not choosing a bookmark or typing in the address bar!)

2) If the previus and the current page are in the same security
protocol (http / http or https / https)

3) If a particular server re-transmits REFERRER header (most do but
there are exceptions).

4) If a particular browser doesn't lock reading document.referrer
property (I don't know of any though)

if ((typeof document.referrer == 'string')
&&(document.referrer != "")
&&(document.referrer != document.location.href)) {
// I am lucky!
var prevURL = document.referrer;
}

[Thomas 'PointedEars' Lahn]

VK wrote:

Dan wrote:

Is there a way to obtain the last page visited? I don't want to go to
that page, I just want to be able find out what page they came from,
the url of that page. Is this possible?
[...]
2) If the previus and the current page are in the same security
protocol (http / http or https / https)

The Same Origin Policy does not apply here.
3) If a particular server re-transmits REFERRER header (most do but
there are exceptions).
The Referer header is a _request_ header, it is be sent by the client
only (RFC2616, 14.36), if that.
4) If a particular browser doesn't lock reading document.referrer
property (I don't know of any though)

if ((typeof document.referrer == 'string')
&&(document.referrer != "")
&&(document.referrer != document.location.href)) {
// I am lucky!
var prevURL = document.referrer;
}

if (document.referrer // not undefined, not the empty string
&& document.referrer != window.location
{
// I am lucky!
var prevURL = document.referrer;
}
PointedEars

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

if (document.referrer // not undefined, not the empty string

&& document.referrer != window.location)
PointedEars

[VK]

Thomas 'PointedEars' Lahn wrote:

2) If the previus and the current page are in the same security
protocol (http / http or https / https)

The Same Origin Policy does not apply here.

Christmas time is time of forgiveness (and fresh victimes in the next
year) :-)

It is not Same Origin Policy issue, but security level upgrade /
degrade

Say if the previous page was _https_://www.server1.com and the current
page is _http_://www.server2.com then you will not be allowed to read
document.referrer (security degrade) Same for vice versa.

Do not look for it in W3C - they have no clue about such things. But it
works like this accross all browsers (mind to experiment?)

[Thomas 'PointedEars' Lahn]

VK wrote:

Thomas 'PointedEars' Lahn wrote:

> 2) If the previus and the current page are in the same security
> protocol (http / http or https / https)
The Same Origin Policy does not apply here.

[...]
It is not Same Origin Policy issue, but security level upgrade /
degrade

Say if the previous page was _https_://www.server1.com and the current
page is _http_://www.server2.com then you will not be allowed to read
document.referrer (security degrade) Same for vice versa.

ACK, that is probably/hopefully so. However I do think that is instead
due to the Referer HTTP header sent or not sent by the client, and not
specific to the document.referrer property.

Your misuse of the term `same security protocol' confused me. HTTP and
HTTPS (HTTP over SSL/TLS) are only transfer protocols. The _cryptographic_
or _encryption_ protocol used for the latter is SSL/TLS.

<URL:http://en.wikipedia.org/wiki/HTTPS>
Do not look for it in W3C - they have no clue about such things.
But it works like this accross all browsers (mind to experiment?)

No thanks, I have currently no need for a public key certificate for my Web
site and requesting a key just for the purpose of document.referrer testing
is not worth the effort. Maybe somebody else volunteers.
PointedEars

[VK]

Thomas 'PointedEars' Lahn wrote:

VK wrote:

Thomas 'PointedEars' Lahn wrote:

> 2) If the previus and the current page are in the same security
> protocol (http / http or https / https)

The Same Origin Policy does not apply here.

[...]
It is not Same Origin Policy issue, but security level upgrade /
degrade

Say if the previous page was _https_://www.server1.com and the current
page is _http_://www.server2.com then you will not be allowed to read
document.referrer (security degrade) Same for vice versa.

ACK, that is probably/hopefully so. However I do think that is instead
due to the Referer HTTP header sent or not sent by the client, and not
specific to the document.referrer property.

Your misuse of the term `same security protocol' confused me. HTTP and
HTTPS (HTTP over SSL/TLS) are only transfer protocols. The _cryptographic_
or _encryption_ protocol used for the latter is SSL/TLS.

Well, this is a common shortcut to say "secure connection" or "secure
protocol" about HTTPS, but we can put it in a totally streightforward
way by saying:
"If the referrer page and the current page are using different levels
of security access: HTTP - HTTPS or HTTPS - HTTP then document.referrer
property access will be blocked" (you may say even better :-).

It is a life implied rule - this is why W3C is not aware of it. The
reason is that the security context switch usually connected with
login/logout operations. Therefore by sniffing referrer someone can get
some GET-connected (so in URI contained) access details. That become
really actual after many providers switched on in/out HTTPS scheme for
resource effectiveness: from HTTP your submit login data to HTTPS form
which redirect you right back to HTTP, so only login data transmission
goes by HTTPS. After several major security exploits everyone fixed
document.referrer in the described way.

[Thomas 'PointedEars' Lahn]

VK wrote:

Thomas 'PointedEars' Lahn wrote:

VK wrote:

> Thomas 'PointedEars' Lahn wrote:
>> > 2) If the previus and the current page are in the same security ^^^^^^^^^^^^^^^^^^^^^^^^ >> > protocol (http / http or https / https) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> The Same Origin Policy does not apply here.
> [...]
> It is not Same Origin Policy issue, but security level upgrade /
> degrade
>
> Say if the previous page was _https_://www.server1.com and the current
> page is _http_://www.server2.com then you will not be allowed to read
> document.referrer (security degrade) Same for vice versa.
[...]
Your misuse of the term `same security protocol' confused me. HTTP and
HTTPS (HTTP over SSL/TLS) are only transfer protocols. The
_cryptographic_ or _encryption_ protocol used for the latter is SSL/TLS.

Well, this is a common shortcut to say "secure connection" or "secure
protocol" about HTTPS,

You wrote "_security_ protocol" which is wrong.
[windings snipped]

PointedEars

[VK]

Thomas 'PointedEars' Lahn:

You wrote "_security_ protocol" which is wrong.

HTTPS (Hypertext Transfer Protocol over Secure Socket Layer, or HTTP
over SSL)

In common use it is called "security protocol" or "secure protocol"
(check Cisco, Sun and Co).

Wiki... well... it is a good thing for common (and specially
non-standard) info but very dangerous for definitions. I would prefer
in the latter case an opinion of actual inventors or developers.

[Thomas 'PointedEars' Lahn]

VK wrote:

Thomas 'PointedEars' Lahn:

You wrote "_security_ protocol" which is wrong.
HTTPS (Hypertext Transfer Protocol over Secure Socket Layer, or HTTP
over SSL)

Or over TLS, the successor of SSL.
In common use it is called "security protocol" or "secure protocol"
There is a huge difference in meaning between the term "security protocol"
for HTTS, which is wrong, and the term "secure protocol", which is right.

And even if that were so (I wonder what "common use" means to a person
with so many misconceptions as you): so what? In "common use" the
(World Wide) Web, but an Internet application, is called "the Internet"
which is awfully wrong.
(check Cisco, Sun and Co).
No, you are to prove your statement ("common use") in order to argue
for it. Search <URL:http://en.wikipedia.org/wiki/Logical_fallacy> for
"Shifting the burden of proof".
Wiki... well... it is a good thing for common (and specially
non-standard) info
Yes, it is.
but very dangerous for definitions.
No, it is not.
I would prefer in the latter case an opinion of actual inventors or
developers.

I prefer common _sense_. However, developers, perhaps even the
"inventors" of HTTPS, have most certainly participated in writing
that article. Your assumption that only laymen participate in Wikis
and that Wikis are therefore of little reliability is unfounded.
PointedEars

[Thomas 'PointedEars' Lahn]

VK wrote:

Thomas 'PointedEars' Lahn:

You wrote "_security_ protocol" which is wrong.
HTTPS (Hypertext Transfer Protocol over Secure Socket Layer, or HTTP
over SSL)

Or over TLS, the successor of SSL.
In common use it is called "security protocol" or "secure protocol"
There is a huge difference in meaning between the term "security protocol"
for HTTPS, which is wrong, and the term "secure protocol", which is right.

And even if that were so (I wonder what "common use" means to a person
with so many misconceptions as you): so what? In "common use" the
(World Wide) Web, but an Internet application, is called "the Internet"
which is awfully wrong.
(check Cisco, Sun and Co).
No, you are to prove your statement ("common use") in order to argue
for it. Search <URL:http://en.wikipedia.org/wiki/Logical_fallacy> for
"Shifting the burden of proof".
Wiki... well... it is a good thing for common (and specially
non-standard) info
Yes, it is.
but very dangerous for definitions.
No, it is not.
I would prefer in the latter case an opinion of actual inventors or
developers.

I prefer common _sense_. However, developers, perhaps even the
"inventors" of HTTPS, have most certainly participated in writing
that article. Your assumption that only laymen participate in Wikis
and that Wikis are therefore of little reliability is unfounded.
PointedEars

[VK]

Thomas 'PointedEars' Lahn wrote:

I prefer common _sense_. However, developers, perhaps even the
"inventors" of HTTPS, have most certainly participated in writing
that article. Your assumption that only laymen participate in Wikis
and that Wikis are therefore of little reliability is unfounded.

oky-toky, I'm a bit lost now:
So then one is going from http://... to https:// or from https:// to
http://... then *properly* should be said that ...?
https is "encripted" <something>, that's rather easy. but what is
http:// then? "decripted", "open", "plain"?

[Thomas 'PointedEars' Lahn]

VK wrote:

Thomas 'PointedEars' Lahn wrote:

I prefer common _sense_. However, developers, perhaps even the
"inventors" of HTTPS, have most certainly participated in writing
that article. Your assumption that only laymen participate in Wikis
and that Wikis are therefore of little reliability is unfounded.
oky-toky, I'm a bit lost now:
So then one is going from http://... to https:// or from https:// to
http://... then *properly* should be said that ...?

.... they are accessing a resource that is served over an encrypted (HTTPS)
connection from a resource that is served over an unencrypted (HTTP)
connection and vice-versa. (YMMV)
https is "encripted" <something>, that's rather easy. but what is
http:// then? "decripted", "open", "plain"?

Un_encrypted_. That /was/ easy :)
PointedEars