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.
Related
I've defined a route in web.php that looks like this:
Route::delete('/app/charges-for-order/{orderId}', 'AppController#deleteOrderCharges');
It seems to work well apart from when orderId has a forward slash in it. Eg 11/11.
Naturally my first port of call was to generate the url in the frontend using encodeURIComponent:
/app/charges-for-order/${encodeURIComponent(orderId)} (in javascript)
Which produces the url /app/charges-for-order/11%2F11, replacing the forward slash with %2F -- however, this is giving me a 404, as if Laravel is still seeing %2F as a forward slash for routing purposes.
How can I allow orderId to have (encoded) forward slashes and still be part of the URL like that? Is there some alternate encoding scheme that Laravel will respect in this context?
Use where() clause in route file. Which allows you to use RegEx in the file.
->where('orderId', '^[0-9/]+$'); # or
->where('orderId', '[0-9/]+'); # this
Read - Regular Expression Constraints
IMPORTANT: Do not use ->where('orderId', '.*') or ->where('orderId', '.') any cost.
Side Note: I'm not debugging the DELETE route works or not, just testing whether you can pass params. As well, if you found extensive RegEx, use it. I used this for testing purposes, but still, it does the job
I tested with http://127.0.0.1:8090/app/charges-for-order/11/11 in my local, and the result was
I assume you are using Apache as HTTP server? At least Apache is by default decoding %2F behind your back: https://httpd.apache.org/docs/2.4/mod/core.html#allowencodedslashes
Changing this might be a bad idea, so I would suggest you would change your route to match all:
Route::delete('/app/charges-for-order/{orderId}', 'AppController#deleteOrderCharges')
->where('orderId', '.+');
I ended up just changing the methods in question to accept query parameters or post data instead, I was having trouble with the other answers.
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."
I had this url regex pattern in place:
$pattern = "#\b(https?://[^\s()<>\[\]\{\}]{1,".$max_length_allowed_for_each_url."}(?:\([\w\d]+\)|([^[:punct:]\s]|/)))#";
It seemed to work pretty well at validating any URL I threw at it, until I realized that https://http://google.com (apparently even stackoverflow is considering that a valid URL (it made that URL clickable, not me, although it did remove one of the colons) so perhaps I am out of luck?) was a valid URL, when it certainly is not.
I did a little research... and learnt that I should be using filter_var instead of a regex for PHP URL validation anyways... and was disappointed to realize that it too is susceptible to this very same validation problem.
I could easily conquer it with:
str_replace(array("https://http://","http://https://"), array("http://","https://"), $url);
But... that just seems so wrong.
Well, it is a valid URI. Technically. Look at the RFC for URIs if you don't believe me.
The path component of a URI can contain //.
http is a valid host name.
The port is allowed to be missing even if the : is present (it's specified as *digit, not 1*digit). (This is why Stack Overflow removed the colon -- it thought you were using the default port, so it removed it from the URI.)
I suggest writing a special case for this. In a separate step, check to see if the URI starts with https?://https?://, and fix it.
I have a URL like this
http://www.freshupnow.com/movie.php?moviename=A+Flat
I want to rewrite this URL using .htaccess code like this
http://www.freshupnow.com/movies/A+Flat
So, I have used the following code for this
RewriteRule ^movies/([A-Za-z0-9-]+)/?$ movie.php?moviename=$1 [NC,L]
Can Some one please verify it, Either it is Right or Wrong?
([A-Za-z0-9-]+) should be ([A-Za-z0-9+])+ coz you want to capture the whole group 1 or more times and you also want to allow "+" character in your movie names, as in the example "A+Flat". You can validate your regex yourself using this online tool: Regex Validate. There are several others, try Googling for it.
I was looking for ways to mimic something I've seen, however I'm really not even sure where to start or how to search for it.
Lets say my page was:
foo.com/ and my index page could take an argument of: index.php?id=5
What I'm wanting to do is create the following:
foo.com/5/ rather than placing index.php?id=5 just use the webstring to pass in the parameters, to hide not only the fact its a PHP page, but to clean up the url a bit more.
Is this possible?
Cheers
You'll want to look into URL rewriting. With the commonly used Apache webserver, this is accomplished with mod_rewrite.
or /?5/123/
and in php parse the query string if rewrite is not available
Something like this should suit:
RewriteRule ^pages/([A-Za-z_-]*)(/?)$ /index.php?page=$1
Broken down, we're looking for a URL that starts with pages, has any combination of letters, underscores and hyphens, and an optional trailing forward slash, and passing that to /index.php to handle.
Yes Mod_rewrite is best option, you can create .htaccess file. if you do not want the write a custom function which will handle the your url.