Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #9903 > unrolled thread

$referrer = $_SERVER['HTTP_REFERER'] echo

Back to article view | Back to comp.lang.php

Contents

  $referrer = $_SERVER['HTTP_REFERER'] echo Twayne <nobody@spamcop.net> - 2013-06-27 17:23 -0400
    RESOLVED Re: $referrer = $_SERVER['HTTP_REFERER'] echo Twayne <nobody@spamcop.net> - 2013-06-27 17:34 -0400
    Re: $referrer = $_SERVER['HTTP_REFERER'] echo Christoph Michael Becker <cmbecker69@arcor.de> - 2013-06-27 23:40 +0200
      Re: $referrer = $_SERVER['HTTP_REFERER'] echo Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-28 00:19 +0200
        Re: $referrer = $_SERVER['HTTP_REFERER'] echo Christoph Michael Becker <cmbecker69@arcor.de> - 2013-06-28 02:16 +0200
          Re: $referrer = $_SERVER['HTTP_REFERER'] echo Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-28 10:56 +0200
            Re: $referrer = $_SERVER['HTTP_REFERER'] echo Christoph Michael Becker <cmbecker69@arcor.de> - 2013-06-28 20:03 +0200
              Re: $referrer = $_SERVER['HTTP_REFERER'] echo Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-28 21:49 +0200
                Re: $referrer = $_SERVER['HTTP_REFERER'] echo Christoph Michael Becker <cmbecker69@arcor.de> - 2013-06-28 22:37 +0200
                  Re: $referrer = $_SERVER['HTTP_REFERER'] echo Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-28 23:55 +0200
        Re: $referrer = $_SERVER['HTTP_REFERER'] echo Twayne <nobody@spamcop.net> - 2013-06-28 13:49 -0400
          Re: $referrer = $_SERVER['HTTP_REFERER'] echo Christoph Michael Becker <cmbecker69@arcor.de> - 2013-06-28 20:13 +0200
      Re: $referrer = $_SERVER['HTTP_REFERER'] echo Twayne <nobody@spamcop.net> - 2013-06-28 13:33 -0400
    Re: $referrer = $_SERVER['HTTP_REFERER'] echo Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-27 17:52 -0400
      Re: $referrer = $_SERVER['HTTP_REFERER'] echo Twayne <nobody@spamcop.net> - 2013-06-28 14:07 -0400
        Re: $referrer = $_SERVER['HTTP_REFERER'] echo Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-28 15:26 -0400
          Re: $referrer = $_SERVER['HTTP_REFERER'] echo Twayne <nobody@spamcop.net> - 2013-06-28 16:03 -0400
            Re: $referrer = $_SERVER['HTTP_REFERER'] echo Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-28 16:07 -0400
              Re: $referrer = $_SERVER['HTTP_REFERER'] echo Christoph Michael Becker <cmbecker69@arcor.de> - 2013-06-28 22:46 +0200
                Re: $referrer = $_SERVER['HTTP_REFERER'] echo Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-28 23:58 +0200

#9903 — $referrer = $_SERVER['HTTP_REFERER'] echo

I have what's probably a simple and very basic question.

My goal is to see where a visitor sending a form-email with mail() on 
win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the 
right page or just barge into this page as his landing page?
   My php.ini seems to be OK and I've not changed any other config 
files. All other "If's" work OK and I'm now baffled.

This works fine:
-------------------
$referrer = $_SERVER['HTTP_REFERER'];
echo "<br /><br /> Visitor came here from : ". substr($referrer, -13, 
13)."<br />";
------------------

But this will not work:
------------------------------
if(substr($referrer, -13, 13))==="formcheck.php") {echo "Something 
showed up";
}
-----------------------------

It results in the following error:
------------
Parse error: syntax error, unexpected T_IS_IDENTICAL in 
C:\xampp\htdocs\formcheck2.php on line 36
------------
when when run on my local XAMPP Server.

I have tried everything I can think of to get it to work: Interchaning 
the vars on each side of "===", using "==",  moved the closing parens 
around, with and without curly brackets, etc. etc. etc. I've got myself 
so confused now I feel really stuck.

Can anyone straighten me out?

TIA,

Twayne

[toc] | [next] | [standalone]

#9904 — RESOLVED Re: $referrer = $_SERVER['HTTP_REFERER'] echo

<sigh>, never mind. Makes a big difference when a dufus gets his head on 
straight.  Went back to basics and:
----------------------
if (substr($referrer, -13, 13)=="formcheck.php"){
   echo "Came from correct page <br />";
}
else {
echo "came from WRONG PAGE!";
}
---------------------

works fine.  Who said I was a dufus, huh?  ;)

Twayne`

[toc] | [prev] | [next] | [standalone]

#9905

Twayne wrote:
> I have what's probably a simple and very basic question.
> 
> My goal is to see where a visitor sending a form-email with mail() on
> win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
> right page or just barge into this page as his landing page?

You should be aware that it is possible that a UA doesn't sent a
referrer header.

>   My php.ini seems to be OK and I've not changed any other config files.
> All other "If's" work OK and I'm now baffled.
> 
> This works fine:
> -------------------
> $referrer = $_SERVER['HTTP_REFERER'];
> echo "<br /><br /> Visitor came here from : ". substr($referrer, -13,
> 13)."<br />";
> ------------------
> 
> But this will not work:
> ------------------------------
> if(substr($referrer, -13, 13))==="formcheck.php") {echo "Something
> showed up";
> }
> -----------------------------

The double )) is wrong; just use a single ).  You may consider to use
only simple expressions for an if expression, e.g.:

  $cameFromExpectedPage = substr($referrer, -13) === 'formcheck.php';
  if ($cameFromExpectedPage) {
    echo 'Something showed up';
  }

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#9907

Christoph Michael Becker wrote:

> […] You may consider to use only simple expressions for an if expression,
> e.g.:
> 
>   $cameFromExpectedPage = substr($referrer, -13) === 'formcheck.php';
>   if ($cameFromExpectedPage) {
>     echo 'Something showed up';
>   }

Good idea, but I would write

  $cameFromExpectedPage = (substr($referrer, -13) === 'formcheck.php');

for even greater clarity.

Also, I would let match RFC 3986, Appendix B, against a URI.  What if there 
is a query part, for example?

But I would never check against the HTTP-Referer [sic!] in the first place.  
There are much more reliable solutions, like session variables.  See also 
<https://owasp.org/>.


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [next] | [standalone]

#9908

Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
> 
>> […] You may consider to use only simple expressions for an if expression,
>> e.g.:
>>
>>   $cameFromExpectedPage = substr($referrer, -13) === 'formcheck.php';
>>   if ($cameFromExpectedPage) {
>>     echo 'Something showed up';
>>   }
> 
> Good idea, but I would write
> 
>   $cameFromExpectedPage = (substr($referrer, -13) === 'formcheck.php');
> 
> for even greater clarity.

ACK.

> Also, I would let match RFC 3986, Appendix B, against a URI.  What if there 
> is a query part, for example?

Good point!  However, only recently there was a bug report regarding
PHP's filter_var($var, FILTER_VALIDATE_URL)[1].  This is meant to be
implemented according to RFC 2396; obviously RFC 2396 is obsoleted by
RFC 3986 (I was not aware of that until now--thank you).  Anyway, it
seems the regular expression given in Appendix B of RFC 2396 *seems* to
be more permissive than the actual syntax given in Appendix A.  I have
not checked RFC 3986 regarding this issue yet.

> But I would never check against the HTTP-Referer [sic!] in the first place.  
> There are much more reliable solutions, like session variables.  See also 
> <https://owasp.org/>.

ACK.  OTOH I have some concerns regarding cookies (I do not "like" to
propagate session IDs as a GET parameter) due to the European cookie law(s).

[1] <https://bugs.php.net/bug.php?id=65141>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#9910

Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Also, I would let match RFC 3986, Appendix B, against a URI.  What if
>> there is a query part, for example?
> 
> Good point!  However, only recently there was a bug report regarding
> PHP's filter_var($var, FILTER_VALIDATE_URL)[1].

I have not suggested using filter_var().

> This is meant to be implemented according to RFC 2396; obviously RFC 2396
> is obsoleted by RFC 3986

Since 8 years now. 

> (I was not aware of that until now--thank you).

You're welcome.

> Anyway, it seems the regular expression given in Appendix B of RFC 2396
> *seems* to be more permissive than the actual syntax given in Appendix A.

Appendixes are not normative.  Assuming relevance, in which way does it seem 
more permissive?

> I have not checked RFC 3986 regarding this issue yet.
> 
>> But I would never check against the HTTP-Referer [sic!] in the first
>> place. There are much more reliable solutions, like session variables. 
>> See also <https://owasp.org/>.
> 
> ACK.  OTOH I have some concerns regarding cookies (I do not "like" to
> propagate session IDs as a GET parameter) due to the European cookie
> law(s).

Directive 95/46/EC does not apply here.

> [1] <https://bugs.php.net/bug.php?id=65141>


PointedEars, IANAL
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#9919

Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
>> Thomas 'PointedEars' Lahn wrote:

>> Anyway, it seems the regular expression given in Appendix B of RFC 2396
>> *seems* to be more permissive than the actual syntax given in Appendix A.
> 
> Appendixes are not normative.  Assuming relevance, in which way does it seem 
> more permissive?

The following example passes the regular expression in Appendix B of RFC
2396, but it is not allowed according to Appendix A (if I'm not mistaken):

  http://http://example.com

>> I have not checked RFC 3986 regarding this issue yet.
>>
>>> But I would never check against the HTTP-Referer [sic!] in the first
>>> place. There are much more reliable solutions, like session variables. 
>>> See also <https://owasp.org/>.
>>
>> ACK.  OTOH I have some concerns regarding cookies (I do not "like" to
>> propagate session IDs as a GET parameter) due to the European cookie
>> law(s).
> 
> Directive 95/46/EC does not apply here.

I was referring to directive 2009/136/EC, which *might* apply.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#9925

Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>> Anyway, it seems the regular expression given in Appendix B of RFC 2396
>>> *seems* to be more permissive than the actual syntax given in Appendix
>>> A. 
>> Appendixes are not normative.  Assuming relevance, in which way does it
>> seem more permissive?
> 
> The following example passes the regular expression in Appendix B of RFC
> 2396, but it is not allowed according to Appendix A (if I'm not mistaken):
> 
>   http://http://example.com

You are mistaken.  The relevant productions are:

  URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
  absoluteURI   = scheme ":" ( hier_part | opaque_part )
  scheme        = alpha *( alpha | digit | "+" | "-" | "." )
  hier_part     = ( net_path | abs_path ) [ "?" query ]
  abs_path      = "/"  path_segments
  path_segments = segment *( "/" segment )
  segment       = *pchar *( ";" param )
  pchar         = unreserved | escaped |
                  ":" | "@" | "&" | "=" | "+" | "$" | ","
  unreserved    = alphanum | mark
  mark          = "-" | "_" | "." | "!" | "~" | "*" | "'" |
                  "(" | ")"
  alphanum      = alpha | digit
  alpha         = lowalpha | upalpha
  lowalpha      = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
                  "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
                  "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"

Applied:

     URI-reference
  => [ absoluteURI | relativeURI ] [ "#" fragment ]
  => absoluteURI
  => scheme ":" ( hier_part | opaque_part )
  => scheme ":" hier_part
  => scheme ":" ( net_path | abs_path ) [ "?" query ]
  => scheme ":" abs_path
  => scheme ":" "/" path_segments
  => scheme ":" "/" segment *( "/" segment )
  => scheme ":" "/" segment "/" segment "/" segment "/" segment
  => scheme ":" "/" *pchar *( ";" param ) "/" *pchar *( ";" param ) "/" 
*pchar *( ";" param ) "/" *pchar *( ";" param )
  => scheme ":" "/" *pchar "/" *pchar "/" *pchar "/" *pchar
  => scheme ":" "/" "" "/" pchar pchar pchar pchar pchar "/" "" "/" pchar 
pchar pchar pchar pchar pchar pchar pchar pchar pchar pchar
  => scheme ":" "/" "" "/" unreserved unreserved unreserved unreserved ":" 
"/" "" "/" unreserved unreserved unreserved unreserved unreserved unreserved 
unreserved unreserved unreserved unreserved unreserved
  => scheme ":" "/" "" "/" alphanum alphanum alphanum alphanum ":" "/" "" 
"/" alphanum alphanum alphanum alphanum alphanum alphanum alphanum mark 
alphanum alphanum alphanum
  => scheme ":" "/" "" "/" alpha alpha alpha alpha ":" "/" "" "/" alpha 
alpha alpha alpha alpha alpha alpha mark alpha alpha alpha
  => scheme ":" "/" "" "/" lowalpha lowalpha lowalpha lowalpha ":" "/" "" 
"/" lowalpha lowalpha lowalpha lowalpha lowalpha lowalpha lowalpha mark 
lowalpha lowalpha lowalpha
  => scheme ":" "/" "" "/" "h" "t" "t" "p" ":" "/" "" "/" "e" "x" "a" "m" 
"p" "l" "e" "." "c" "o" "m"
  => alpha *( alpha | digit | "+" | "-" | "." ) ":" "/" "" "/" "h" "t" "t" 
"p" ":" "/" "" "/" "e" "x" "a" "m" "p" "l" "e" "." "c" "o" "m"
  => alpha alpha alpha alpha ":" "/" "" "/" "h" "t" "t" "p" ":" "/" "" "/" 
"e" "x" "a" "m" "p" "l" "e" "." "c" "o" "m"
  => lowalpha lowalpha lowalpha lowalpha ":" "/" "" "/" "h" "t" "t" "p" ":" 
"/" "e" "x" "a" "m" "p" "l" "e" "." "c" "o" "m"
  => "h" "t" "t" "p" ":" "/" "" "/" "h" "t" "t" "p" ":" "/" "" "/" "e" "x" 
"a" "m" "p" "l" "e" "." "c" "o" "m"
  => "http://http:/example.com"

[Some day I'll write an automatic grammar resolver.  And I should let prove 
other people their unfounded statements instead of going to lengths 
disproving them.]
  
These productions were probably not intended.  But note that the section is 
titled “*Parsing* a URI Reference with a Regular Expression”, _not_ 
“*Validating* a URI Reference”, and that URI References also include things 
like “javascript:window.alert("42");”.
 
>>> I have not checked RFC 3986 regarding this issue yet.
>>>
>>>> But I would never check against the HTTP-Referer [sic!] in the first
>>>> place. There are much more reliable solutions, like session variables.
>>>> See also <https://owasp.org/>.
>>>
>>> ACK.  OTOH I have some concerns regarding cookies (I do not "like" to
>>> propagate session IDs as a GET parameter) due to the European cookie
>>> law(s).
>> 
>> Directive 95/46/EC does not apply here.
> 
> I was referring to directive 2009/136/EC, which *might* apply.

How?


PointedEars 
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#9929

Thomas 'PointedEars' Lahn:
> Christoph Michael Becker wrote:
> 
>> Thomas 'PointedEars' Lahn wrote:
>>> Christoph Michael Becker wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>> Anyway, it seems the regular expression given in Appendix B of RFC 2396
>>>> *seems* to be more permissive than the actual syntax given in Appendix
>>>> A. 
>>> Appendixes are not normative.  Assuming relevance, in which way does it
>>> seem more permissive?
>>
>> The following example passes the regular expression in Appendix B of RFC
>> 2396, but it is not allowed according to Appendix A (if I'm not mistaken):
>>
>>   http://http://example.com
> 
> You are mistaken.
>
> <snipped proof>

Thank you very much for proofing me wrong. :)  (I had not though about
the fact that a segment may be empty.)

> [Some day I'll write an automatic grammar resolver.  And I should let prove 
> other people their unfounded statements instead of going to lengths 
> disproving them.]

My apologies for having bothered you.  Actually I had thought about
writing a parser to check it myself, but I have only some experience
with Coco/R[1] which only processes LL(1) grammars.  Lex/Yacc would have
been more useful in this case.

> These productions were probably not intended.  But note that the section is 
> titled “*Parsing* a URI Reference with a Regular Expression”, _not_ 
> “*Validating* a URI Reference”, and that URI References also include things 
> like “javascript:window.alert("42");”.
>  
>>>> I have not checked RFC 3986 regarding this issue yet.
>>>>
>>>>> But I would never check against the HTTP-Referer [sic!] in the first
>>>>> place. There are much more reliable solutions, like session variables.
>>>>> See also <https://owasp.org/>.
>>>>
>>>> ACK.  OTOH I have some concerns regarding cookies (I do not "like" to
>>>> propagate session IDs as a GET parameter) due to the European cookie
>>>> law(s).
>>>
>>> Directive 95/46/EC does not apply here.
>>
>> I was referring to directive 2009/136/EC, which *might* apply.
> 
> How?

Article 2 of the directive[2] §5 states:

| Article 5(3) shall be replaced by the following:
|
| ‘3. Member States shall ensure that the storing of infor­mation, or
| the gaining of access to information already stored, in the terminal
| equipment of a subscriber or user is only allowed on condition that
| the subscriber or user con­cerned has given his or her consent, having
| been provided with clear and comprehensive information, in accordance
| with Directive 95/46/EC, inter alia, about the purposes of the
| processing. This shall not prevent any technical storage or access
| for the sole purpose of carrying out the transmission of a
| communication over an electronic communications net­ work, or as
| strictly necessary in order for the provider of an information
| society service explicitly requested by the sub­ scriber or user to
| provide the service.’;

I assume that this concerns all kinds of HTTP cookies.  In the given
case the cookie is probably not covered by the second sentence.
However, IANAL.

[1] <http://www.ssw.uni-linz.ac.at/coco/>
[2]
<http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:337:0011:0036:en:PDF>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#9937

Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn:
>> Christoph Michael Becker wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Christoph Michael Becker wrote:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Anyway, it seems the regular expression given in Appendix B of RFC
>>>>> 2396 *seems* to be more permissive than the actual syntax given in
>>>>> Appendix A.
>>>> Appendixes are not normative.  Assuming relevance, in which way does it
>>>> seem more permissive?
>>>
>>> The following example passes the regular expression in Appendix B of RFC
>>> 2396, but it is not allowed according to Appendix A (if I'm not
>>> mistaken):
>>>
>>>   http://http://example.com
>> 
>> You are mistaken.
>>
>> <snipped proof>
> 
> Thank you very much for proofing me wrong. :)  (I had not though about
> the fact that a segment may be empty.)

The possibility occurred to me only after I went down the “net_path” path as 
you probably did, which lead nowhere (in disproving you).

>> [Some day I'll write an automatic grammar resolver.  And I should let
>> [prove other people their unfounded statements instead of going to
>> lengths disproving them.]
> 
> My apologies for having bothered you. 

You have not bothered me.  It was an interesting problem to hack, after all.  
It was *my* mistake: I should not invite “shifting the burden of proof” 
fallacies by doing things like this (but I know you did not intend that).

> Actually I had thought about writing a parser to check it myself, but I
> have only some experience with Coco/R[1] which only processes LL(1)
> grammars.  Lex/Yacc would have been more useful in this case.

I have played a bit with JFlex while studying CS.  Perhaps this could be an 
approach.  Thanks.
 
>>>>> I have not checked RFC 3986 regarding this issue yet.
>>>>>
>>>>>> But I would never check against the HTTP-Referer [sic!] in the first
>>>>>> place. There are much more reliable solutions, like session
>>>>>> variables. See also <https://owasp.org/>.
>>>>> ACK.  OTOH I have some concerns regarding cookies (I do not "like" to
>>>>> propagate session IDs as a GET parameter) due to the European cookie
>>>>> law(s).
>>>> Directive 95/46/EC does not apply here.
>>> I was referring to directive 2009/136/EC, which *might* apply.
>> 
>> How?

(See?  I did it :))
 
> Article 2 of the directive[2] §5 states:
> 
> | Article 5(3) shall be replaced by the following:
> |
> | ‘3. Member States shall ensure that the storing of infor­mation, or
> | the gaining of access to information already stored, in the terminal
> | equipment of a subscriber or user is only allowed on condition that
> | the subscriber or user con­cerned has given his or her consent, having
> | been provided with clear and comprehensive information, in accordance
> | with Directive 95/46/EC, inter alia, about the purposes of the
         ^^^^^^^^^^^^^^^^^^
> | processing. This shall not prevent any technical storage or access
> | for the sole purpose of carrying out the transmission of a
> | communication over an electronic communications net­ work, or as
> | strictly necessary in order for the provider of an information
> | society service explicitly requested by the sub­ scriber or user to
> | provide the service.’;
> 
> I assume that this concerns all kinds of HTTP cookies.  In the given
> case the cookie is probably not covered by the second sentence.

I think the *session* cookie *is* covered there.  It is stored and used only 
for making sure that the user is still in the same session.  Also, there is 
this (unreferenced) statement:

,-<http://en.wikipedia.org/wiki/HTTP_cookie#EU_Cookie_Law>
| 
| In June 2012, European data protection authorities adopted an opinion
| which clarifies that some cookie users might be exempt from the
| requirement to gain consent:
| 
| - Some cookies can be exempted from informed consent under certain
|   conditions if they are not used for additional purposes. These cookies
|   include cookies used to keep track of a user’s input when filling online
|   forms or as a shopping cart.

Subsequent paragraphs describe and reference the negative reaction to the 
“cookie law”.  I also remember to have seen at the time, as a negative 
reaction, a series of ridiculous popups representing what would need to 
happen if that Directive was taken seriously.

> However, IANAL.
> 
> [1] <http://www.ssw.uni-linz.ac.at/coco/>
> [2]
> <http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:337:0011:0036:en:PDF>

IANAL either, and this discussion about layman interpretations of legalese 
is probably leading nowhere except perhaps “reasonable doubt”.

However, AIUI Directive 95/46/EC *referred there* explicitly excludes 
*session* cookies as it mandates:

<http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:HTML>

| Article 2
| Definitions
| For the purposes of this Directive:
| (a) 'personal data' shall mean any information relating to an identified
| or identifiable natural person ('data subject'); an identifiable person is
| one who can be identified, directly or indirectly, in particular by
| reference to an identification number or to one or more factors specific
| to his physical, physiological, mental, economic, cultural or social
| identity;
| […]
| 
| Article 3
| Scope
| 1. This Directive shall apply to the processing of personal data wholly or
| partly by automatic means, and to the processing otherwise than by
| automatic means of personal data which form part of a filing system or are
| intended to form part of a filing system.

IMHO it excludes session cookies because they are not “information relating 
to an identified or identifiable natural person”.  At most you can identify 
this way an HTTP client running on a computer that one individual *or more* 
(say, a family household or office people) are using.

That said, an EU “directive is a legislative act of the European Union,[1] 
which requires member states to achieve a particular result without 
dictating the means of achieving that result.” (Wikipedia)

If you think about it: Is is likely that all those companies located in the 
EU that use PHP sessions in their Web application are in violation of the 
law?  Why have they continued doing business and never ever anyone has sued 
them?

I think I understand at least a bit of legalese; there is /de jure/ and /de 
facto/.  While /de jure/ it *might* be necessary to ask the user explicitly 
before setting a session cookie, /de facto/ it is the user who defined in 
their browser settings to accept session cookies or to be asked about them 
and then confirms that they are set in order to use the application.  That 
also includes the session cookie set for the PHP session ID.


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#9918

On 2013-06-27 6:19 PM, Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
>

...

> for even greater clarity.
>
> Also, I would let match RFC 3986, Appendix B, against a URI.  What if there
> is a query part, for example?

I haven't read the RFC yet, only glanced at it, but it looks like the 
kind of thing I can use.  Thanks!
    Question:  by "query", are you referring to using a database? 
Otherwise I'm not sure what you meant, now what the problem may be.


>
> But I would never check against the HTTP-Referer [sic!] in the first place.

    Why is that? If an attempted entry is made from other than the forms 
paths, it'll show up on my own screen quickly. Is it easy to spoof or what?



> There are much more reliable solutions, like session variables.  See also
> <https://owasp.org/>.

I am also using Session variables and unsetting them as soon as I'm done 
with them and destroying the session at first opportunity after it's no 
longer needed. But I'm not sure I see why that's better than checking 
the referrer?

owasp.org btw looks like a keeper! I've bookmarked it and intend to 
spend some time there.  THANKS AGAIN!

Regards,

Twayne`
>
>
> PointedEars
>

[toc] | [prev] | [next] | [standalone]

#9921

Twayne wrote:
> On 2013-06-27 6:19 PM, Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>
>> Also, I would let match RFC 3986, Appendix B, against a URI.  What if
>> there
>> is a query part, for example?
> 
> I haven't read the RFC yet, only glanced at it, but it looks like the
> kind of thing I can use.  Thanks!
>    Question:  by "query", are you referring to using a database?
> Otherwise I'm not sure what you meant, now what the problem may be.

Thomas is referring to a potential query part of the refer(r)er URI
(casually spoken: everything between ? and #).  If a query part is
contained in the refer(r)er URI, the last 13 characters won't be the
expected filename.

>> But I would never check against the HTTP-Referer [sic!] in the first
>> place.
> 
>    Why is that? If an attempted entry is made from other than the forms
> paths, it'll show up on my own screen quickly. Is it easy to spoof or what?

It is very easy to spoof the refer(r)er header[1]--as any other user
supplied input to a website.

[1] <http://en.wikipedia.org/wiki/Referer_spoofing>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#9917

On 2013-06-27 5:40 PM, Christoph Michael Becker wrote:
> Twayne wrote:
>> I have what's probably a simple and very basic question.
>>
>> My goal is to see where a visitor sending a form-email with mail() on
>> win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
>> right page or just barge into this page as his landing page?
>

...

> The double )) is wrong; just use a single ).  You may consider to use
> only simple expressions for an if expression, e.g.:
>
>    $cameFromExpectedPage = substr($referrer, -13) === 'formcheck.php';
>    if ($cameFromExpectedPage) {
>      echo 'Something showed up';
>    }
>

Duh!  That helped; thank you!

Twayne`

[toc] | [prev] | [next] | [standalone]

#9906

On 6/27/2013 5:23 PM, Twayne wrote:
> I have what's probably a simple and very basic question.
>
> My goal is to see where a visitor sending a form-email with mail() on
> win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
> right page or just barge into this page as his landing page?
>    My php.ini seems to be OK and I've not changed any other config
> files. All other "If's" work OK and I'm now baffled.
>
> This works fine:
> -------------------
> $referrer = $_SERVER['HTTP_REFERER'];
> echo "<br /><br /> Visitor came here from : ". substr($referrer, -13,
> 13)."<br />";
> ------------------
>
> But this will not work:
> ------------------------------
> if(substr($referrer, -13, 13))==="formcheck.php") {echo "Something
> showed up";
> }
> -----------------------------
>
> It results in the following error:
> ------------
> Parse error: syntax error, unexpected T_IS_IDENTICAL in
> C:\xampp\htdocs\formcheck2.php on line 36
> ------------
> when when run on my local XAMPP Server.
>
> I have tried everything I can think of to get it to work: Interchaning
> the vars on each side of "===", using "==",  moved the closing parens
> around, with and without curly brackets, etc. etc. etc. I've got myself
> so confused now I feel really stuck.
>
> Can anyone straighten me out?
>
> TIA,
>
> Twayne
>

Like anything else sent by the client, you can't trust 
$_SERVER['HTTP_REFERER'].  It may or may not exist, and if it does, it 
may or may not contain the actual referrer page.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#9920

On 2013-06-27 5:52 PM, Jerry Stuckle wrote:
> On 6/27/2013 5:23 PM, Twayne wrote:
>> I have what's probably a simple and very basic question.
>>
>> My goal is to see where a visitor sending a form-email with mail() on
>> win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
>> right page or just barge into this page as his landing page?
>>    My php.ini seems to be OK and I've not changed any other config
>> files. All other "If's" work OK and I'm now baffled.

...

>
> Like anything else sent by the client, you can't trust
> $_SERVER['HTTP_REFERER'].  It may or may not exist, and if it does, it
> may or may not contain the actual referrer page.

Perhaps you can expand on that? Referrer does exist, and it's sent to me 
by my server. If it doesn't indicate MY previous form page, then I know 
the visito and it reflects ONLY my own files to be accepted, or hasn't 
used the website link to access that particular page, or has tried some 
sort of direct access, Back Button, etc.; and I destroy the session and 
stop the script.

TIA for enlightening me.

Twayne`

[toc] | [prev] | [next] | [standalone]

#9923

On 6/28/2013 2:07 PM, Twayne wrote:
> On 2013-06-27 5:52 PM, Jerry Stuckle wrote:
>> On 6/27/2013 5:23 PM, Twayne wrote:
>>> I have what's probably a simple and very basic question.
>>>
>>> My goal is to see where a visitor sending a form-email with mail() on
>>> win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
>>> right page or just barge into this page as his landing page?
>>>    My php.ini seems to be OK and I've not changed any other config
>>> files. All other "If's" work OK and I'm now baffled.
>
> ...
>
>>
>> Like anything else sent by the client, you can't trust
>> $_SERVER['HTTP_REFERER'].  It may or may not exist, and if it does, it
>> may or may not contain the actual referrer page.
>
> Perhaps you can expand on that? Referrer does exist, and it's sent to me
> by my server. If it doesn't indicate MY previous form page, then I know
> the visito and it reflects ONLY my own files to be accepted, or hasn't
> used the website link to access that particular page, or has tried some
> sort of direct access, Back Button, etc.; and I destroy the session and
> stop the script.
>
> TIA for enlightening me.
>
> Twayne`
>
>
>
>

It is supplied by the user, and like anything user-supplied, can easily 
be spoofed.  And some people don't even send it (I've heard Norton has 
an option to strip it, but haven't confirmed that fact).

Just because it exists and is correct on your system does NOT mean it 
exists or is correct when coming from other systems!

The bottom line is - it is user-supplied data, and you should NEVER 
trust user-supplied data.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#9927

On 2013-06-28 3:26 PM, Jerry Stuckle wrote:
> On 6/28/2013 2:07 PM, Twayne wrote:
>> On 2013-06-27 5:52 PM, Jerry Stuckle wrote:
>>> On 6/27/2013 5:23 PM, Twayne wrote:
>>>> I have what's probably a simple and very basic question.
>>>>
>>>> My goal is to see where a visitor sending a form-email with mail() on
>>>> win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
>>>> right page or just barge into this page as his landing page?
>>>>    My php.ini seems to be OK and I've not changed any other config
>>>> files. All other "If's" work OK and I'm now baffled.
>>
>> ...
>>
>>>

...

>>
>
> It is supplied by the user, and like anything user-supplied, can easily
> be spoofed.  And some people don't even send it (I've heard Norton has
> an option to strip it, but haven't confirmed that fact).

No, it is NOT supplied by the user in this case. It is supplied by the 
server of my website, and the only information I'm interested in is 
whether the visitor came from the proper page on my website; nothing 
else shall pass. You've said nothing to change my mind, but thanks anyway.
>
> Just because it exists and is correct on your system does NOT mean it
> exists or is correct when coming from other systems!

I have zero interest in "other systems", as I described previously.

On my server, not my "system". It's entirely server-side operations. 
Others are reporting my scheme as a "good one" when considering 
everything the forest contains; possibly even more than really  needed.
>
> The bottom line is - it is user-supplied data, and you should NEVER
> trust user-supplied data.

like I said, it's not user-supplied.

The user knows nothing about it without some pretty clever attention to 
the problem and hacking the server I use (NOT mine-standard, reputable 
servers).

Thanks for the response, even if it was rather lacking in any detail 
that I found useful.

Twayne`

>

[toc] | [prev] | [next] | [standalone]

#9928

On 6/28/2013 4:03 PM, Twayne wrote:
> On 2013-06-28 3:26 PM, Jerry Stuckle wrote:
>> On 6/28/2013 2:07 PM, Twayne wrote:
>>> On 2013-06-27 5:52 PM, Jerry Stuckle wrote:
>>>> On 6/27/2013 5:23 PM, Twayne wrote:
>>>>> I have what's probably a simple and very basic question.
>>>>>
>>>>> My goal is to see where a visitor sending a form-email with mail() on
>>>>> win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
>>>>> right page or just barge into this page as his landing page?
>>>>>    My php.ini seems to be OK and I've not changed any other config
>>>>> files. All other "If's" work OK and I'm now baffled.
>>>
>>> ...
>>>
>>>>
>
> ...
>
>>>
>>
>> It is supplied by the user, and like anything user-supplied, can easily
>> be spoofed.  And some people don't even send it (I've heard Norton has
>> an option to strip it, but haven't confirmed that fact).
>
> No, it is NOT supplied by the user in this case. It is supplied by the
> server of my website, and the only information I'm interested in is
> whether the visitor came from the proper page on my website; nothing
> else shall pass. You've said nothing to change my mind, but thanks anyway.

Check again.  HTTP_REFERER is supplied by the CLIENT.  The server has no 
idea where the page was called from.

>>
>> Just because it exists and is correct on your system does NOT mean it
>> exists or is correct when coming from other systems!
>
> I have zero interest in "other systems", as I described previously.
>

You should.  It's your clients who are using those other systems!

> On my server, not my "system". It's entirely server-side operations.
> Others are reporting my scheme as a "good one" when considering
> everything the forest contains; possibly even more than really  needed.
>>
>> The bottom line is - it is user-supplied data, and you should NEVER
>> trust user-supplied data.
>
> like I said, it's not user-supplied.
>

Try again.  The server has no idea what page the client was on when he 
clicked on a link (or whatever).

> The user knows nothing about it without some pretty clever attention to
> the problem and hacking the server I use (NOT mine-standard, reputable
> servers).
>

The client knows EVERYTHING about it.  It supplies the value.

> Thanks for the response, even if it was rather lacking in any detail
> that I found useful.
>
> Twayne`
>
>>
>

Then I would suggest you get some more education.  Try running the HTTP 
Headers extension under Firefox - you will find the value being sent by 
the browser.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#9931

Jerry Stuckle wrote:
> On 6/28/2013 4:03 PM, Twayne wrote:
>> On 2013-06-28 3:26 PM, Jerry Stuckle wrote:
>>> It is supplied by the user, and like anything user-supplied, can easily
>>> be spoofed.  And some people don't even send it (I've heard Norton has
>>> an option to strip it, but haven't confirmed that fact).
>>
>> No, it is NOT supplied by the user in this case. It is supplied by the
>> server of my website, and the only information I'm interested in is
>> whether the visitor came from the proper page on my website; nothing
>> else shall pass. You've said nothing to change my mind, but thanks
>> anyway.
> 
> Check again.  HTTP_REFERER is supplied by the CLIENT.  The server has no
> idea where the page was called from.

ACK.  See RFC 2616 section 14.36.[1]

>> Thanks for the response, even if it was rather lacking in any detail
>> that I found useful.
> 
> Then I would suggest you get some more education.  Try running the HTTP
> Headers extension under Firefox - you will find the value being sent by
> the browser.

If sending the refer(r)er header has not been disabled.[2]

[1] <http://www.ietf.org/rfc/rfc2616.txt>
[2] <http://www.technipages.com/firefox-enable-disable-referrer.html>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#9938

Christoph Michael Becker wrote:

> Jerry Stuckle wrote:
>> On 6/28/2013 4:03 PM, Twayne wrote:
>>> Thanks for the response, even if it was rather lacking in any detail
>>> that I found useful.
>> 
>> Then I would suggest you get some more education.  Try running the HTTP
>> Headers extension under Firefox - you will find the value being sent by
>> the browser.
> 
> If sending the refer(r)er header has not been disabled.[2]
> 
> [1] <http://www.ietf.org/rfc/rfc2616.txt>
> [2] <http://www.technipages.com/firefox-enable-disable-referrer.html>

Also, developer tools' (including Firebug's) “Net(work)” tab is infinitely 
more useful these days.  Just press F12.


PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web