http://localhost/foo/profile/%26lt%3Bi%26gt%3Bmarco%26lt%3B%2Fi%26gt%3B
The url above gives me a 404 Error, the url code is this: urlencode(htmlspecialchars($foo));, as for the $foo: <i>badhtml</i>
The url works fine when there's nothing to encode e.g. marco.
Thanks. =D
Update: I'm supposed to capture the segment in the encoded part of the uri, so a 404 isn't supposed to appear.
There isn't any document there, marco is simply the string that I needed to fetch that person's info from db. If the user doesn't exist, it won't throw that ugly error anyways.
Slight idea what's wrong: I found out that if I used <i>badhtml<i>, it works just fine but <i>badhtml</i> won't, what do I do so that I can maintain the / in the <i>?
It probably think of the request as http://localhost/foo/profile/<i>badhtml<**/**i>
Since there is a slash / in the parameter, this is getting interpreted as a path name separator.
The solution, therefore, is to replace all occurrences of a slash with something that doesn't get interpreted as a separator. \u2044 or something. And when reading the parameter back in, change all \u2044s back to normal slashes.
(I chose \u2044 because this character looks remarkably like a normal slash, but you can use anthing that would never occur in the parameter, of course.)
It is most likely that the regex responsible for handling the URL rewrite does not like some of the characters in the URL-encoded string. This is most likely httpd/apache question, rather than PHP. Your best guess is to start by looking at the .htaccess (file containing URL rewrite rules).
This question assumes that your are trying to pass an argument through the URL, rather than access a file named <i>badhtml</i>.
Mr. Lister, you rocked.
"The solution, therefore, is to replace all occurrences of a slash with something that doesn't get interpreted as a separator. \u2044 or something. And when reading the parameter back in, change all \u2044s back to normal slashes."
Related
Hi guys may I ask why is my isset failed to ready parameter from the url?
The second picture is I tried to pass a id parameter into it
You didn't explain precisely what the code is doing instead of what you expected, but from the code we can see some likely issues:
Your URL looks wrong:
A # in a URL normally tells the browser to move to an anchor in the current page, not send a request to the server
Unless you've got some system for enabling "pretty" URLs then you'll need to put the .php extension on the end of the filename in the URL
%s isn't a number or ID, it looks like it might be a placeholder for string replacement, but it's unclear from the code you've shown whether the text is actually inside some sort of string / command where replacement would occur.
A valid-looking example (relative) URL to put into your link might be something like delAcc.php?id=1, so
<a href="delAcc.php?id=1" class="fas fas-user-minus">
in PHP, variables inside single-quoted strings are not interpolated, so you'd get $id literally shown on screen in the alert.
You need to double-quote the string:
echo "<script>alert($id)</script>";
I'm making an API, everything is handled inside the file, so here's what an example URL might look like.
https://website.com/api/?type=search&user=bob
And I'd want that to turn into
https://website.com/api/search/bob
But now here's the other part to this issue. I have another type, which is CSRF
https://website.com/api/?type=csrf
And that would be
https://website.com/api/csrf/
Note that it's one parameter short, but yet still working off the same file. Anything i've tried never seems to work correctly. Additionally there always seems to be a \ added to the api file. I've already removed the .php from there.
So when I try this it doesn't work. Any ideas?
rewrite ^/([a-zA-Z0-9_-]+)/([0-9]+)$ /api/?type=$1&user=$2;
Your problem seems to be that you use $2 for your username and this correspond to ([0-9]+) in your regular expression.
Which means, username will have to be numbers only.
Change your expression to :
rewrite ^/([a-zA-Z0-9\_\-]+)/([a-zA-Z0-9\_\-]+)$ /api/?type=$1&user=$2;
And your rules should work.
I'm interested in extracting the directory from $_SERVER['REQUEST_URI']. I believe I specifically need to use $_SERVER['REQUEST_URI'] in case the URL is being mod_rewrite'd.
If $_SERVER['REQUEST_URI'] = 'http://example.com/path/to/resource';, then I can just use dirname() on it and get http://example.com/path/to.
If the URI is the directory index page/equivalent, but a query string or hash is appended to it, then $_SERVER['REQUEST_URI'] might be something like 'http://example.com/path/?query' or http://example.com/path/#hash. In this case, dirname() works as well -- both of those resolve to http://example.com/path.
If, however, the URI has no query string or hash, pathname() strips off the bottom-level directory, e.g. http://example.com/path/ becomes http://example.com. My solution was to simply append a hash symbol to every URI, i.e. dirname($_SERVER['REQUEST_URI'].'#'). dirname('http://example.com/path/'.'#') yields http://example.com/path.
But I don't understand how URIs work, so I don't really know if this is safe.
If a URI points to a directory, does it always end in the character /? If I type http://example.com/path in my browser, it redirects to http://example.com/path/, adding the trailing slash. Will this always happen, though?
Do query strings and hashes always get URL-encoded? For example, I can type http://example.com/path/?query=a/b/c in my browser and it gets interpreted as http://example.com/path/?query=a%2Bb%2Bc. But if that conversion didn't happen, then pathname() would return http://example.com/path/?query=a/b, which would be bad.
Can URIs have \s or are directories always separated with /?
I have seen plenty of people having this problem and it seems the only way to stop apache treating the encoded ampersand and a URL ampersand is it use the mod rewrite B flag, RewriteRule ^(.*)$ index.php?path=$1 [L,QSA,B].
However, this isn't available in earlier versions of apache and has to be installed which is also not supported by some hosting companies.
I have found a solution that works well for us. We have a url of /search/results/Takeaway+Foods/Inverchorachan,+Argyll+&+Bute+
This obviously breaks the url at & giving us /search/results/Takeaway+Foods/Inverchorachan,+Argyll which then gives a 404 error as there is no such page.
The url is held in the $_GET['url'] array. If it finds an & the it splits the array for each ampersand.
The following code pieces the URL back together by traversing the $_GET array for each piece.
I would like to know if this has any hidden problems that I may not be aware of.
The code:
$newurl = "";
foreach($_GET as $key=>$pcs) {
if($newurl=="")
$newurl = $pcs;
else
$newurl .= "& ".rtrim($key,"_");
}
//echo $newurl;exit;
if($newurl!='') $url=$newurl;
I am trimming the underscore from the piece as apache added this. Not sure why but any help on this would be great.
You said in a cooment:
We want the URL to show the ampersand so substituting with other characters is not an option.
Short answer: Don't do it.
Seriously, don't use ampersands this way in URLs. Even if looks pretty. Ampersands have a special meaning in a URL and trying to override that meaning because it looks nice is a very bad idea.
Most web-based software (including Apache, PHP and all browsers) makes assumptions about what an ampersand means in a URL, which you will find very hard to work around.
In particular, you will utterly confuse Google and other search engines if you've got arbitrary ampersands in the URL, so it will completely destroy your SEO rank.
If you must have an ampersand in the string, use urlencoding to turn it into a URL-friendly %26. This won't look good in the user's URL string, but it will work as intended.
If that's not acceptable, then substitute something different for ampersands; maybe the word "and", or a character like and underscore, or perhaps just remove it from the string without a replacement.
All of these are common practice. Trying to force the URL to have an actual ampersand character in it is not common practice, and for very good reason.
Take a look at urlencode :
You can also replace the "&" char with something not breaking the URI and won't be interpreted by apache like the "|" char.
We have had this fix in place for two weeks now so I believe that this has solved the issue. I hope this will help someone with a similar issue as I searched for weeks for a solution outside of an apache upgrade to include the B flag. Our users can now type in Bed & Breakfast and we can then serve the appropriate page.
Here is the fix in PHP.
$newurl = "";
foreach($_GET as $key=>$pcs)
{
if($newurl=="")
$newurl = $pcs;
else
$newurl .= "& ".rtrim($key,"_");
}
if($newurl!='') $url=$newurl;
I saw some request like
www.example.com/start.php?404;http://www.example.com:80
but unfortunately can't understand if it is a valid url or how it will work.
www.example.com/start.php?404
and
http://www.example.com:80
and
www.example.com/start.php?404;http://www.example.com:80
are all valid URLs. But since ; is not a reserved symbol, it needs to be URL encoded. See Characters allowed in a URL for the list of characters allowed in a URL.
I don't think its a valid url. It redirects you to a 404 page. The http://www.example.com:80 is probably wrong set so it enters a complete url at the end of the already standing url.
Maybe i am wrong.