I have a POST route setup called user/connect which points to the relevant controller function ( which expects post varialbles), but adding a trailing slash e.g. user/connect/ redirects it to GET thus returning "MethodNotAllowedHttpException"
I am unable to remove the forward slash ( as the consuming app is sending it and i have no control ) . Any pointers on how i could get the route with the trailing slash to also point to my POST route ?
You should use ‘php artisan list:route’ to find a conflicting route. Laravel will not alter the HTTP method. The app could also be wrong so some investigation is needed there as well.
Fixed using user3532758 comment, seems that if i remove the following from the public/.htaccess it fixes it, but i am not sure if it opens up another security hole so checking that as well
removing the following fixes it:
# Redirect Trailing Slashes If Not A Folder...
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} (.+)/$
RewriteRule ^ %1 [L,R=301]
Related
we have a REST Api, that declares the following routes for entity:
Route::get('entities', 'Api2EntityController#index');
Route::get('entities/{entityId}', 'Api2EntityController#show');
Route::post('entities', 'Api2EntityController#store');
Route::put('entities/{entityId}', 'Api2EntityController#update');
Route::delete('entities/{entityId}', 'Api2EntityController#destroy');
POSTing data to entities would correctly call Api2EntityController#store.
But the same request to entities/ (has trailing '/') would call Api2EntityController#index.
we have tried adding a new route for POST or using regex or changing the order of the routes, still we have no solution so far on how to accept the POST on the URL with trailing '/'
There is a rewrite active to remove any trailing slashes.
Check your public/.htaccess file
# Redirect Trailing Slashes...
RewriteRule ^(.*)/$ /$1 [L,R=301]
I have a website using MODx Revolution (2.2.10-pl, advanced install), let's call it www.example.com, which I want to be accessible with both http and https.
to achieve this, I tweaked the site_url context setting to be [[++url_scheme]]www.example.com/. Links created using [[~id]] seem to be alright, however, sometimes, the generated links are really weird. My interpretation is that the code to create links programmatically doesn't work with my settings, but I don't know why, or how else I would go about enabling both http and https.
Question first, examples below: How should I set the site_url or any other site/context setting so that links on my site work with both http and https? Optionally, is the behavior I see a bug, or expected behavior given Revolution's tag evaluation semantics?
Misbehavior examples:
When I click on "View" in the manager for a resource with the alias example, the address that is opened is
https://www.example.com/xyz/[[++url_scheme]]www.example.com/example/
where xyz is my manager URL. The expected URL is of course
https://www.example.com/example/
Another case where this happens is for failed logins; my login call looks like this (minus irrelevant parts):
[[!Login? &redirectToOnFailedAuth=`[[++unauthorized_page]]`]]
The unauthorized_page's expected full URL is
https://www.example.com/special/401
but the URL which is opened for a failed login as username is
https://www.example.com/[[++url_scheme]]www.example.com/[[++url_scheme]]www.example.com/special/401?u=username
The second example is the same for http, except for the scheme, of course; I haven't logged into the manager with http.
EDIT
.htaccess at the webroot:
RewriteEngine On
RewriteBase /
# redirect all requests to /en/favicon.ico to /favicon.ico
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(en)/favicon.ico$ favicon.ico [L,QSA]
#RewriteRule ^(en|nl|de)/favicon.ico$ favicon.ico [L,QSA]
# redirect all requests to /en/assets* /assets*
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(en)/assets(.*)$ assets$2 [L,QSA]
#RewriteRule ^(en|nl|de)/assets(.*)$ assets$2 [L,QSA]
# redirect all other requests to /en/*
# to index.php and set the cultureKey parameter
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(en)?/?(.*)$ index.php?cultureKey=$1&q=$2 [L,QSA]
#RewriteRule ^(en|nl|de)?/?(.*)$ index.php?cultureKey=$1&q=$2 [L,QSA]
.htaccess in the manager's directory:
RewriteEngine On
RewriteBase /
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/xyz/$1
The problem is with $modx->makeUrl(). For example, for the
[[!Login? &redirectToOnFailedAuth=`[[++unauthorized_page]]`]]
call, in core/components/login/controllers/web/Login.php:
public function checkForRedirectOnFailedAuth(modProcessorResponse $response) {
$redirectToOnFailedAuth = $this->getProperty('redirectToOnFailedAuth',false,'isset');
if ($redirectToOnFailedAuth && $redirectToOnFailedAuth != $this->modx->resource->get('id')) {
$p = array(
'u' => $this->dictionary->get('username'),
);
$message = $response->getMessage();
if (!empty($message)) $params['m'] = $message;
$url = $this->modx->makeUrl($redirectToOnFailedAuth,'',$p,'full');
$this->modx->sendRedirect($url);
}
}
the last two lines do a redirect to a URL generated with makeUrl, which will be something like [[++url_scheme]]www.example.com/etc (note: I'm not 100% sure here, as I can't easily look at the raw URL. The conclusions still hold, though). If the URL is simply shown on the page, this is no problem, because MODx will parse the tag before inserting it into the html output. However, as the URL is used directly for the redirect, no such replacement takes place, and the browser interprets it as a relative URL, resulting in target URLs such as https://www.example.com/[[++url_scheme]]www.example.com/etc.
So much for the problem. To avoid this, site_url must be a literal value without any tags in it. As a workaround, I now use the following snippet as the first thing in my template:
$modx->config['site_url'] = $modx->config['url_scheme'] . substr($modx->config['site_url'], strlen('[[++url_scheme]]'));
return '';
together with a [[++site_url]] of
[[++url_scheme]]www.example.com/
Note that some parts of MODx don't seem to notice this update, which is why it's important to still use [[++url_scheme]] in your site_url. As far as I can tell right now, the parts that don't see the update, stuff like [[~id]], work properly with url_scheme.
EDIT this does of course only fix the "View" buttons in the manager if you tweak the manager templates accordingly.
WARNING this is of course very hacky, and not yet tested very well. The fact that some features do not see the overwritten value means that you're introducing an inconsistency into your website, which may lead to subtle errors! If a more clean solution comes up, go for it!
I'm trying to reformat my url to be a bit shorter. Right now the links end up as this: website.com/image?id=name.jpg
What I want to have the link come out as is m.website.com/name, without the file exension or image.php file in the url. I figure mod_rewrite is the way to do it, so any help will be greatly appreciated.
In order to make it so someone accessing the URL http://m.website.com/name gets served the content for http://website.com/image?id=name.jpg, you first need to check the hostname for m.website.com, then match the name part of the URI. Using that match, you can proxy the request (using a [P]) or, if both website.com and m.website.com are hosted on the same server, just simply internally rewrite. Try putting this in your .htaccess file in your document root:
RewriteEngine on
# check the host (NC = no case)
RewriteCond %{HTTP_HOST} ^m\.website\.com$ [NC]
# don't rewrite /image
RewriteCond %{REQUEST_URI} !^/image
# Match the first non-slash word and rewrite
RewriteRule ^([^/]+)$ /image?id=$1 [L]
This will rewrite http://m.website.com/name to /image?id=name.jpg, but it will not rewrite http://m.website.com/path/name. If you want paths (and everything else) to be included in the id parameter, change the ([^/]+) to (.*) in the RewriteRule.
I am having a bit of difficulty getting mod_rewrite to do what I need it to do.
We have a group of virtual subdomains in a Drupal install. So, academics.univ.edu, about.univ.edu, etc are all part of the same core Drupal install.
File access currently is academics.univ.edu/sites/all/academics/files/myfile.jpg. However this path will also work as about.univ.edu/sitse/all/about/files/myfile.jpg or any other valid subdomain.
We'd like to use mod_rewrite to accept academics.univ.edu/files/myfile.jpg and deliver the file from the above location.
Here's what I've tried:
RewriteCond %{REQUEST_URI} ^(about|academics|bursar|calendar)\.univ\.edu\/files\/(.*)$ [NC]
RewriteRule ^/sites/all/files/$1/$2 [L,NC]
I'm probably going about this the wrong way, but I wanted to check on it. I can get the subdomains to work by making separate rules using HTTP_HOST, but I wanted less rules in the file. Also, I can't get HTTP_HOST to work on sites that exist as a subdirectory in a subdomian. For instance, undergrad.univ.edu/biology/files/myfile.jpg should deliver /sites/all/biology/files/myfile.jpg
You can't match a host in the %{REQUEST_URI}, you need to use %{HTTP_HOST}, then use the %1 backrefernce to access that match. The actual URI can be matched in the rule itself. Something like this:
RewriteCond %{HTTP_HOST} ^(about|academics|bursar|calendar)\.univ\.edu$ [NC]
RewriteRule ^files/(.*)$ /sites/all/files/%1/%2 [L,NC]
The %1 references the match (about|academics|bursar|calendar) in the RewriteCond and the $1 references the match (.*) in the RewriteRule. So that example will take a request to http://about.univ.edu/files/foo.html and rewrite the request to /sites/all/files/about/foo.html.
Also, if this is in a virtualhost or server config, you need a "/" in between "^" and "files" in the RewriteRule.
I want to redirect all requests to a certain path on my server (/app) to a subdirectory at /app/app_site. Following rewrite rules do the job for requests like 'http://localhost/app/somepage.htm':
RewriteCond %{REQUEST_URI} !^/app/app_site.*$
RewriteCond %{REQUEST_URI} !^/app_site.*$
RewriteRule ^/app(.*) /app/app_site$1 [L,PT]
This results in the correct page, while preserving the URL. Also, 'http://localhost/app/' will fetch the index page at /app/app_site/index.html, while preserving the URL 'http://localhost/app/'.
However, when I enter 'http://localhost/app', following things happen:
the correct page is fetched, at /app/app_site/index.html
yet, the URL is redirected to 'http://localhost/app/app_site/'
I'm nearly there, but would like to preserve the URL in all cases (also those without trailing slash). Anyone have a clue how to do this? Thanks!
This is the expected behaviour with DirectorySlash enabled, because you've rewritten to a directory that lacks a trailing slash, and mod_dir performs this cleanup after you've rewritten the URL with mod_rewrite.
The easiest solution is to rewrite the URL so that it always at least matches the slash-terminated directory path, like so:
RewriteCond %{REQUEST_URI} !^/app/app_site.*$
RewriteCond %{REQUEST_URI} !^/app_site.*$
RewriteRule ^/app/?(.*)$ /app/app_site/$1 [L,PT]
This prevents mod_dir from having to add the trailing slash, and therefore avoids the external redirection to /app/app_site/ you're experiencing now.