Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #16438 > unrolled thread
| Started by | James Harris <james.harris.1@gmail.com> |
|---|---|
| First post | 2016-02-17 09:37 +0000 |
| Last post | 2016-03-22 05:23 -0700 |
| Articles | 20 on this page of 86 — 9 participants |
Back to article view | Back to comp.lang.php
PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-17 09:37 +0000
Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-17 11:05 +0100
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-17 15:04 +0000
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 10:54 -0500
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-18 01:09 +0000
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 21:12 -0500
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-20 19:07 +0000
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-20 21:07 +0100
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-20 20:35 +0000
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-20 21:40 +0100
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-20 21:02 +0000
Re: PHP processing steps to apply to a URL to make it safe gordonb.lkcah@burditt.org (Gordon Burditt) - 2016-02-29 21:29 -0600
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-17 23:33 +0100
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-18 01:12 +0000
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-18 21:48 +0100
Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-18 08:05 +0100
Re: PHP processing steps to apply to a URL to make it safe Tim Streater <timstreater@greenbee.net> - 2016-02-18 09:59 +0000
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-18 10:29 +0000
Re: PHP processing steps to apply to a URL to make it safe Tim Streater <timstreater@greenbee.net> - 2016-02-18 11:36 +0000
Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-18 15:44 +0100
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-18 21:47 +0100
Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-18 08:02 +0100
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-20 19:29 +0000
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-20 21:37 +0100
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-20 21:37 +0000
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-21 15:02 +0100
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-21 15:02 +0000
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 08:19 -0500
Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 14:43 +0100
Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-17 15:04 +0100
Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 15:17 +0100
Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-17 15:47 +0100
Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 15:57 +0100
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 10:57 -0500
Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 17:10 +0100
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 12:11 -0500
Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 18:51 +0100
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 12:55 -0500
Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-17 19:06 +0100
Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 20:19 +0100
Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-18 08:18 +0100
Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-18 09:20 +0100
Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-18 15:48 +0100
Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-18 16:25 +0100
Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-18 17:00 +0100
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-18 22:26 +0100
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-18 10:48 -0500
Re: PHP processing steps to apply to a URL to make it safe "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-02-17 16:38 +0100
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 10:56 -0500
Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-17 19:08 +0100
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-17 23:35 +0100
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 09:56 -0500
Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 16:44 +0100
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 12:12 -0500
Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 19:04 +0100
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 09:55 -0500
Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 16:39 +0100
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 11:00 -0500
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-17 15:15 +0000
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 11:05 -0500
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-18 01:18 +0000
Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-17 19:14 +0100
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-18 00:19 +0000
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-17 23:36 +0100
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-17 23:26 +0100
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-18 00:36 +0000
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-18 22:03 +0100
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-20 19:38 +0000
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-20 21:17 +0100
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-20 20:56 +0000
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-20 23:48 +0100
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-21 09:37 +0000
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-21 14:42 +0100
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-21 15:03 +0000
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-21 14:09 -0500
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-21 19:34 +0000
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-21 14:49 -0500
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-21 19:56 +0000
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-21 20:29 -0500
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-22 07:30 +0000
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-22 08:13 -0500
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-22 15:01 +0000
Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-22 10:31 -0500
Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-22 00:10 +0100
Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-21 23:45 +0000
Re: PHP processing steps to apply to a URL to make it safe pittendrigh <Sandy.Pittendrigh@gmail.com> - 2016-03-22 05:23 -0700
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-02-18 01:18 +0000 |
| Message-ID | <na3606$rj5$1@dont-email.me> |
| In reply to | #16461 |
On 17/02/2016 16:05, Jerry Stuckle wrote: ... [discussion about /../ snipped] > But you also have to ensure it doesn't go other places it shouldn't - > for instance, you may have protected directories in your DOCUMENT_ROOT > which would not normally be accessible. Yes, that is a good reason to outlaw .. entries - one of a few. > You really have to separate the URL into it's individual components and > check each one individually. OK. I do check the path against the file system at the moment (as this is currently identifying a file). I use is_dir() once the request URI string has been vetted and changed. I'll think about whether I should do more checking, though. James
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2016-02-17 19:14 +0100 |
| Message-ID | <56C4B87B.7090205@arnowelzel.de> |
| In reply to | #16452 |
James Harris schrieb am 2016-02-17 um 16:15: > On 17/02/2016 13:19, Jerry Stuckle wrote: > > ... > >> What are you trying to "make safe"? A url is either good or bad. If >> it's bad, it won't bring up a site. If it's good, it will bring up a >> site, but that site may not be safe. > > In this case I use url rewriting to force requests to a PHP script. The > script then has to process the rest of the URL - basically all of the > URL after site:port. For URL rewriting it is better to use the provided functions of your webserver, e.g. Apache mod_rewrite etc.. >> What are you actually trying to accomplish here? I'm not sure how a >> supplied URL will affect your PHP code. > > At the moment I pick up $_SERVER["REQUEST_URI"]. That gives me the rest > of the URL after the site:port part and does not strip off any ; or ? > parts - which allows me to vet the URL including to ensure those parts > are absent. > > Does that make more sense now? So - you want to take the REQUEST_URI, modify its contents and then use the result to do another HTTP request or redirect? In this case you should really think about using Apache rewriting. Or does the "modify the requested URI" involve some local lookups to a database etc.? -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-02-18 00:19 +0000 |
| Message-ID | <na32h3$ifi$1@dont-email.me> |
| In reply to | #16470 |
On 17/02/2016 18:14, Arno Welzel wrote: > James Harris schrieb am 2016-02-17 um 16:15: > >> On 17/02/2016 13:19, Jerry Stuckle wrote: >> >> ... >> >>> What are you trying to "make safe"? A url is either good or bad. If >>> it's bad, it won't bring up a site. If it's good, it will bring up a >>> site, but that site may not be safe. >> >> In this case I use url rewriting to force requests to a PHP script. The >> script then has to process the rest of the URL - basically all of the >> URL after site:port. > > For URL rewriting it is better to use the provided functions of your > webserver, e.g. Apache mod_rewrite etc.. Why is that better? I currently use URL rewriting but only to invoke the PHP script. In PHP code the remainder of the URL is picked up and processed. >>> What are you actually trying to accomplish here? I'm not sure how a >>> supplied URL will affect your PHP code. >> >> At the moment I pick up $_SERVER["REQUEST_URI"]. That gives me the rest >> of the URL after the site:port part and does not strip off any ; or ? >> parts - which allows me to vet the URL including to ensure those parts >> are absent. >> >> Does that make more sense now? > > So - you want to take the REQUEST_URI, modify its contents and then use > the result to do another HTTP request or redirect? I currently take the request URI, validate it, and use it to form the prefix of a file name. That prefix is to be used to select a file. The contents of the file will be converted to HTML. > In this case you should really think about using Apache rewriting. Or > does the "modify the requested URI" involve some local lookups to a > database etc.? I can make the modifications in code just now but I may later make them based a specification read from a configuration file (so it seems to me best to do the modification in PHP rather than with URL rewriting). James
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2016-02-17 23:36 +0100 |
| Message-ID | <5222750.81XvjZrRrl@PointedEars.de> |
| In reply to | #16452 |
James Harris wrote: > On 17/02/2016 13:19, Jerry Stuckle wrote: >> What are you actually trying to accomplish here? I'm not sure how a >> supplied URL will affect your PHP code. > > At the moment I pick up $_SERVER["REQUEST_URI"]. That gives me the rest > of the URL after the site:port part and does not strip off any ; or ? > parts - which allows me to vet the URL including to ensure those parts > are absent. > > Does that make more sense now? No, your approach is simply wrong. -- PointedEars Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2016-02-17 23:26 +0100 |
| Message-ID | <28000155.9IakGmh2Vy@PointedEars.de> |
| In reply to | #16438 |
James Harris wrote: > In line with the principle of a program vetting its input, this is about > vetting the supplied URL. > > In order to process a URL or parts of a URL in PHP what processing ought > to be applied to it? I have been using some steps which I will write > below but I am becoming increasingly uncertain that I have covered all > the bases. > > The main concern is safety - ensuring that the PHP code is protected > against anything that might otherwise trip it up. The second concern is > correctness in even corner cases such as odd browsers or extended > character sets. > > I have been working with $_SERVER["REQUEST_URI"], in case that is > relevant. It is relevant: Do not do that. Request parameter values are provided in properly decoded form through specific superglobal arrays such as $_GET, and the $_SERVER['PATH_INFO'] value. <http://php.net/manual/en/reserved.variables.php> > Steps so far: > > urldecode to convert %nn etc Use rawurldecode(), if that. > trim "/" from the ends in order to normalise Nonsense. > check each character is from an allowed set Why? > check there are no // parts Why? > check there are no .. parts Why? That is _not_ a proper measure to make sure that code does not perform filesystem access above the DOCUMENT_ROOT. It smells of unsafe include/require. Fix the problem, not the symptom. > All needed? Any not needed? Latest firefox strips out any .. entries > before sending the URL but I am not sure that all earlier browsers would. Please read the PHP Manual on security, and visit <https://owasp.org/> to get yourself a minimum clue. -- PointedEars Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-02-18 00:36 +0000 |
| Message-ID | <na33h1$l5j$1@dont-email.me> |
| In reply to | #16476 |
On 17/02/2016 22:26, Thomas 'PointedEars' Lahn wrote: > James Harris wrote: ... >> I have been working with $_SERVER["REQUEST_URI"], in case that is >> relevant. > > It is relevant: Do not do that. Request parameter values are provided in > properly decoded form through specific superglobal arrays such as $_GET, > and the $_SERVER['PATH_INFO'] value. No good. PATH_INFO does not contain the query string, AIUI, whereas REQUEST_URI does. ... >> Steps so far: >> >> urldecode to convert %nn etc > > Use rawurldecode(), if that. I'll think about it. I may want the + decode. >> trim "/" from the ends in order to normalise > > Nonsense. Is it *guaranteed* that $_SERVER["REQUEST_URI"] will return a string with a leading slash? ... >> check there are no .. parts > > Why? That is _not_ a proper measure to make sure that code does not perform > filesystem access above the DOCUMENT_ROOT. It smells of unsafe > include/require. Fix the problem, not the symptom. No, that's not the reason. >> All needed? Any not needed? Latest firefox strips out any .. entries >> before sending the URL but I am not sure that all earlier browsers would. > > Please read the PHP Manual on security, and visit <https://owasp.org/> to > get yourself a minimum clue. Thanks for the link. James
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2016-02-18 22:03 +0100 |
| Message-ID | <1703763.CG5OWGaxa9@PointedEars.de> |
| In reply to | #16484 |
James Harris wrote: > On 17/02/2016 22:26, Thomas 'PointedEars' Lahn wrote: >> James Harris wrote: >>> I have been working with $_SERVER["REQUEST_URI"], in case that is >>> relevant. >> It is relevant: Do not do that. Request parameter values are provided in >> properly decoded form through specific superglobal arrays such as $_GET, >> and the $_SERVER['PATH_INFO'] value. > > No good. PATH_INFO does not contain the query string, AIUI, whereas > REQUEST_URI does. > > ... There is no need for a "query string" if you use PATH_INFO. Whether the latter is feasible with your server setup and use-case I do not know yet. >>> trim "/" from the ends in order to normalise >> Nonsense. > > Is it *guaranteed* that $_SERVER["REQUEST_URI"] will return a string > with a leading slash? Yes, see RFCs 1945 (HTTP/1.0), 2616 (HTTP/1.1), and 7540 (HTTP/2). Your server-side PHP script would not be executed if the request URI would not refer to it in some way. But trimming “/” from the end*s* is a different issue as that includes *trailing* slashes. >>> check there are no .. parts >> >> Why? That is _not_ a proper measure to make sure that code does not >> perform >> filesystem access above the DOCUMENT_ROOT. It smells of unsafe >> include/require. Fix the problem, not the symptom. > > No, that's not the reason. OK, you need to explain your use-case then if you would like an informed opinion from me. I do not have time to look for it in the rest of the thread and perhaps not find it there. >>> All needed? Any not needed? Latest firefox strips out any .. entries >>> before sending the URL but I am not sure that all earlier browsers >>> would. >> Please read the PHP Manual on security, and visit <https://owasp.org/> to >> get yourself a minimum clue. > > Thanks for the link. You’re welcome. -- PointedEars Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-02-20 19:38 +0000 |
| Message-ID | <naaf5n$7a5$1@dont-email.me> |
| In reply to | #16511 |
On 18/02/2016 21:03, Thomas 'PointedEars' Lahn wrote: > James Harris wrote: > >> On 17/02/2016 22:26, Thomas 'PointedEars' Lahn wrote: >>> James Harris wrote: >>>> I have been working with $_SERVER["REQUEST_URI"], in case that is >>>> relevant. >>> It is relevant: Do not do that. Request parameter values are provided in >>> properly decoded form through specific superglobal arrays such as $_GET, >>> and the $_SERVER['PATH_INFO'] value. >> >> No good. PATH_INFO does not contain the query string, AIUI, whereas >> REQUEST_URI does. >> >> ... > > There is no need for a "query string" if you use PATH_INFO. Whether the > latter is feasible with your server setup and use-case I do not know yet. I need to ensure that there is no query string. >>>> trim "/" from the ends in order to normalise >>> Nonsense. >> >> Is it *guaranteed* that $_SERVER["REQUEST_URI"] will return a string >> with a leading slash? > > Yes, see RFCs 1945 (HTTP/1.0), 2616 (HTTP/1.1), and 7540 (HTTP/2). Your > server-side PHP script would not be executed if the request URI would not > refer to it in some way. Thanks for the links but IIRC I found in at least one test that a request for the home page as in http://site.com will not have a leading slash on the $_SERVER["REQUEST_URI"]. On balance, I think I will keep the check for a leading slash. In fact, I found that adding a leading slash if PHP did not pass me one made for easier later processing - especially on PHP functions which did not behave well given an empty string. James
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2016-02-20 21:17 +0100 |
| Message-ID | <2319797.8AR7HHlkXX@PointedEars.de> |
| In reply to | #16535 |
James Harris wrote:
> On 18/02/2016 21:03, Thomas 'PointedEars' Lahn wrote:
>> James Harris wrote:
>>> On 17/02/2016 22:26, Thomas 'PointedEars' Lahn wrote:
>>>> […] Do not [use $_SERVER["REQUEST_URI"]]. Request parameter values are
>>>> provided in properly decoded form through specific superglobal arrays
>>>> such as $_GET, and the $_SERVER['PATH_INFO'] value.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> No good. PATH_INFO does not contain the query string, AIUI, whereas
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> REQUEST_URI does.
>>>
>>> ...
>> There is no need for a "query string" if you use PATH_INFO. Whether the
>> latter is feasible with your server setup and use-case I do not know yet.
>
> I need to ensure that there is no query string.
1. You are contradicting your earlier statement.
2. Why?
3. Then you should definitely use PATH_INFO instead of REQUEST_URI.
>>>>> trim "/" from the ends in order to normalise
>>>> Nonsense.
>>> Is it *guaranteed* that $_SERVER["REQUEST_URI"] will return a string
>>> with a leading slash?
>> Yes, see RFCs 1945 (HTTP/1.0), 2616 (HTTP/1.1), and 7540 (HTTP/2). Your
>> server-side PHP script would not be executed if the request URI would not
>> refer to it in some way.
> Thanks for the links but IIRC I found in at least one test that a
> request for the home page as in
>
> http://site.com
>
> will not have a leading slash on the $_SERVER["REQUEST_URI"].
Yes, see <news:20227200.nrqMxn3Nlc@PointedEars.de>; I stand corrected.
> On balance, I think I will keep the check for a leading slash.
Which HTTP client produced this request URI? What was the HTTP server?
> In fact, I found that adding a leading slash if PHP did not pass me one
> made for easier later processing - especially on PHP functions which did
> not behave well given an empty string.
“Talk is cheap. Show me the code.”
—Linus Torvalds
--
PointedEars
Zend Certified PHP Engineer
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-02-20 20:56 +0000 |
| Message-ID | <naajo4$omb$1@dont-email.me> |
| In reply to | #16538 |
On 20/02/2016 20:17, Thomas 'PointedEars' Lahn wrote: > James Harris wrote: > >> On 18/02/2016 21:03, Thomas 'PointedEars' Lahn wrote: >>> James Harris wrote: >>>> On 17/02/2016 22:26, Thomas 'PointedEars' Lahn wrote: >>>>> […] Do not [use $_SERVER["REQUEST_URI"]]. Request parameter values are >>>>> provided in properly decoded form through specific superglobal arrays >>>>> such as $_GET, and the $_SERVER['PATH_INFO'] value. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> No good. PATH_INFO does not contain the query string, AIUI, whereas > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> REQUEST_URI does. >>>> >>>> ... >>> There is no need for a "query string" if you use PATH_INFO. Whether the >>> latter is feasible with your server setup and use-case I do not know yet. >> >> I need to ensure that there is no query string. > > 1. You are contradicting your earlier statement. > > 2. Why? > > 3. Then you should definitely use PATH_INFO instead of REQUEST_URI. I don't think there is a contradiction. Let me give an example with this URL http://example.com/folder/file?greet=hello;lang=en#top If that was presented to the server I would need to see the following string /folder/file?greet=hello&lang=en In my PHP code I would report that as invalid because the query string is unacceptable. I need to see the query string so that I can report a request containing one as invalid. The ?, = and & characters would all be reported as errors. Current report: Invalid character in URL: "?" Invalid character in URL: "=" Invalid character in URL: "&" Invalid character in URL: "=" I could make the reporting a bit more user-friendly but it does the job for now. BTW, is there a $_SERVER element that would return the #top part as well? >>>>>> trim "/" from the ends in order to normalise >>>>> Nonsense. >>>> Is it *guaranteed* that $_SERVER["REQUEST_URI"] will return a string >>>> with a leading slash? >>> Yes, see RFCs 1945 (HTTP/1.0), 2616 (HTTP/1.1), and 7540 (HTTP/2). Your >>> server-side PHP script would not be executed if the request URI would not >>> refer to it in some way. >> Thanks for the links but IIRC I found in at least one test that a >> request for the home page as in >> >> http://site.com >> >> will not have a leading slash on the $_SERVER["REQUEST_URI"]. > > Yes, see <news:20227200.nrqMxn3Nlc@PointedEars.de>; I stand corrected. > >> On balance, I think I will keep the check for a leading slash. > > Which HTTP client produced this request URI? What was the HTTP server? I don't know now if that was correct. I just tried a couple of likely browsers but neither had that effect. The server was Apache. James
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2016-02-20 23:48 +0100 |
| Message-ID | <4923957.ITEB7SZ2Lq@PointedEars.de> |
| In reply to | #16544 |
James Harris wrote: > […] Let me give an example with this URL > > http://example.com/folder/file?greet=hello;lang=en#top > > If that was presented to the server I would need to see the following > string > > /folder/file?greet=hello&lang=en You would not, unless either a) the used index file of the document root, b) “folder”, or c) “folder/file” were PHP programs, and as for the latter two you had enabled content negotiation. But then, either a) $_SERVER['PATH_INFO'] === '/folder/file', b) $_SERVER['PATH_INFO'] === '/file', or c) you had found the file already. Because you would not rewrite *every* request to the same PHP program, would you? > In my PHP code I would report that as invalid because the query string > is unacceptable. > > I need to see the query string so that I can report a request containing > one as invalid. […] Again, why? If you are only interested in the path, what does it matter if there is also a query _part_? And if you are using $_SERVER['PATH_INFO'] for mapping, if you must exclude the case that people also specified a query part you can still test for $_SERVER['QUERY_STRING'] or a set and non-empty $_GET array. Although it can be done, I can still see no reason to sanitize $_SERVER['REQUEST_URI']. > BTW, is there a $_SERVER element that would return the #top part as well? No, as that is not a part of the *request* URI. -- PointedEars Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.a
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-02-21 09:37 +0000 |
| Message-ID | <nac0bn$pst$1@dont-email.me> |
| In reply to | #16549 |
On 20/02/2016 22:48, Thomas 'PointedEars' Lahn wrote: > James Harris wrote: > >> […] Let me give an example with this URL >> >> http://example.com/folder/file?greet=hello;lang=en#top >> >> If that was presented to the server I would need to see the following >> string >> >> /folder/file?greet=hello&lang=en > > You would not, unless either > > a) the used index file of the document root, > b) “folder”, or > c) “folder/file” > > were PHP programs, and as for the latter two you had enabled content > negotiation. But then, either > > a) $_SERVER['PATH_INFO'] === '/folder/file', > b) $_SERVER['PATH_INFO'] === '/file', or > c) you had found the file already. > > Because you would not rewrite *every* request to the same PHP program, would > you? Pretty much, yes. All of this is about processing such URLs in PHP code. >> In my PHP code I would report that as invalid because the query string >> is unacceptable. >> >> I need to see the query string so that I can report a request containing >> one as invalid. […] > > Again, why? If you are only interested in the path, what does it matter if > there is also a query _part_? As I explained in another post, the URL is treated for this as a unique key. Aside from certain rules for matching, it would be wrong in this application for two URLs to map to the same data. > And if you are using $_SERVER['PATH_INFO'] for mapping, if you must exclude > the case that people also specified a query part you can still test for > $_SERVER['QUERY_STRING'] or a set and non-empty $_GET array. Although it > can be done, I can still see no reason to sanitize $_SERVER['REQUEST_URI']. Yes, that's true, I could check that the query string is absent. Good point. >> BTW, is there a $_SERVER element that would return the #top part as well? > > No, as that is not a part of the *request* URI. OK. James
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2016-02-21 14:42 +0100 |
| Message-ID | <44128107.0nCDYgxU9z@PointedEars.de> |
| In reply to | #16556 |
James Harris wrote: > On 20/02/2016 22:48, Thomas 'PointedEars' Lahn wrote: >> Because you would not rewrite *every* request to the same PHP program, >> would you? > > Pretty much, yes. All of this is about processing such URLs in PHP code. That is a stupid idea. -- PointedEars Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-02-21 15:03 +0000 |
| Message-ID | <nacjee$u47$2@dont-email.me> |
| In reply to | #16567 |
On 21/02/2016 13:42, Thomas 'PointedEars' Lahn wrote: > James Harris wrote: > >> On 20/02/2016 22:48, Thomas 'PointedEars' Lahn wrote: >>> Because you would not rewrite *every* request to the same PHP program, >>> would you? >> >> Pretty much, yes. All of this is about processing such URLs in PHP code. > > That is a stupid idea. No, it's the right idea for my application. James
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-02-21 14:09 -0500 |
| Message-ID | <nad1rp$p7i$2@jstuckle.eternal-september.org> |
| In reply to | #16572 |
On 2/21/2016 10:03 AM, James Harris wrote: > On 21/02/2016 13:42, Thomas 'PointedEars' Lahn wrote: >> James Harris wrote: >> >>> On 20/02/2016 22:48, Thomas 'PointedEars' Lahn wrote: >>>> Because you would not rewrite *every* request to the same PHP program, >>>> would you? >>> >>> Pretty much, yes. All of this is about processing such URLs in PHP code. >> >> That is a stupid idea. > > No, it's the right idea for my application. > > James > > One of the rare times I agree with Pointed Head. This is a stupid idea. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-02-21 19:34 +0000 |
| Message-ID | <nad3bd$v60$1@dont-email.me> |
| In reply to | #16579 |
On 21/02/2016 19:09, Jerry Stuckle wrote: > On 2/21/2016 10:03 AM, James Harris wrote: >> On 21/02/2016 13:42, Thomas 'PointedEars' Lahn wrote: >>> James Harris wrote: >>> >>>> On 20/02/2016 22:48, Thomas 'PointedEars' Lahn wrote: >>>>> Because you would not rewrite *every* request to the same PHP program, >>>>> would you? >>>> >>>> Pretty much, yes. All of this is about processing such URLs in PHP code. >>> >>> That is a stupid idea. >> >> No, it's the right idea for my application. > > One of the rare times I agree with Pointed Head. This is a stupid idea. OK, I'll bite. Why? James
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-02-21 14:49 -0500 |
| Message-ID | <nad47a$2ri$1@jstuckle.eternal-september.org> |
| In reply to | #16580 |
On 2/21/2016 2:34 PM, James Harris wrote: > On 21/02/2016 19:09, Jerry Stuckle wrote: >> On 2/21/2016 10:03 AM, James Harris wrote: >>> On 21/02/2016 13:42, Thomas 'PointedEars' Lahn wrote: >>>> James Harris wrote: >>>> >>>>> On 20/02/2016 22:48, Thomas 'PointedEars' Lahn wrote: >>>>>> Because you would not rewrite *every* request to the same PHP >>>>>> program, >>>>>> would you? >>>>> >>>>> Pretty much, yes. All of this is about processing such URLs in PHP >>>>> code. >>>> >>>> That is a stupid idea. >>> >>> No, it's the right idea for my application. > >> >> One of the rare times I agree with Pointed Head. This is a stupid idea. > > OK, I'll bite. Why? > > James > > For all the reasons others and I have mentioned previously. Read back through the thread. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-02-21 19:56 +0000 |
| Message-ID | <nad4l3$448$1@dont-email.me> |
| In reply to | #16581 |
On 21/02/2016 19:49, Jerry Stuckle wrote: > On 2/21/2016 2:34 PM, James Harris wrote: >> On 21/02/2016 19:09, Jerry Stuckle wrote: ... >>> One of the rare times I agree with Pointed Head. This is a stupid idea. >> >> OK, I'll bite. Why? > For all the reasons others and I have mentioned previously. Read back > through the thread. I read every post. I wouldn't ask a question and then not read the replies. James
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-02-21 20:29 -0500 |
| Message-ID | <nado4a$saq$1@jstuckle.eternal-september.org> |
| In reply to | #16582 |
On 2/21/2016 2:56 PM, James Harris wrote: > On 21/02/2016 19:49, Jerry Stuckle wrote: >> On 2/21/2016 2:34 PM, James Harris wrote: >>> On 21/02/2016 19:09, Jerry Stuckle wrote: > > ... > >>>> One of the rare times I agree with Pointed Head. This is a stupid >>>> idea. >>> >>> OK, I'll bite. Why? > >> For all the reasons others and I have mentioned previously. Read back >> through the thread. > > I read every post. I wouldn't ask a question and then not read the replies. > > James > > Obviously you didn't, or you didn't understand. There have been many objections to what you're trying to do by several people. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-02-22 07:30 +0000 |
| Message-ID | <naed9a$bvs$1@dont-email.me> |
| In reply to | #16585 |
On 22/02/2016 01:29, Jerry Stuckle wrote: > On 2/21/2016 2:56 PM, James Harris wrote: >> On 21/02/2016 19:49, Jerry Stuckle wrote: >>> On 2/21/2016 2:34 PM, James Harris wrote: >>>> On 21/02/2016 19:09, Jerry Stuckle wrote: >> >> ... >> >>>>> One of the rare times I agree with Pointed Head. This is a stupid >>>>> idea. >>>> >>>> OK, I'll bite. Why? >> >>> For all the reasons others and I have mentioned previously. Read back >>> through the thread. >> >> I read every post. I wouldn't ask a question and then not read the replies. > Obviously you didn't, Yes, I did. > or you didn't understand. Well, it seems that someone didn't understand. > There have been many > objections to what you're trying to do by several people. As a matter of courtesy I have tried to respond to all the questions I was asked during the discussion as it went ahead. I don't remember anyone having remaining issues with my responses. I don't see what more a person can do to respond to your objections. James
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.php
csiph-web