My Question is this
I redirect the form in
Redirect /formviewer/faces/pages/view/viewform.xhtml
///formviewer/faces/pages/view/viewform.xhtml
in Apache Http Server but the form is not redirecting while doing post request from client Side.
So what is it doing?
I rather suspect that its normalising the thing you want to redirect to ///... and considering it the same.
When looking at redirects, there are three things in my list of 'go-to' tools:
curl -I http://..... and look at the response and the Location header. I use this when installing new redirects (it avoids following chained redirects and gives me a better view of what is happening at each step.
Something like Fiddler or a browsers developer tool. Frankly I'd only use this if curl wasn't doing it for me.
Enable the RewriteLog in Apache... I almost never use this, but for your case it may shed some light.
But let's take a step back: why are you wanting to redirect to a path with and extra // prepended (which as I've previously speculated, likely won't work)?
Related
I'm using Apache and its proxy settings to serve a web page over HTTPS (more detail here: click).
In the previous question, I was struggling with why the POST data was disappearing between my browser and my server. Now I know that it was caused by using Apache's RewriteRule. So I tried working around that with proxies, but this resulted in the web page sending out all other requests on the main domain, instead of the sub domain it's at. For example: My main web page is at myUrl.com/sprinklers. This goes through a proxy, which goes to localhost:8091. The main HTML page loads, but ALL other calls it makes, it makes at myUrl.com/any/path/it/needs, while it should be at myUrl.com/sprinklers/any/path/it/needs.
Sadly, I'm stuck in the middle:
Using RewriteRule means that everything works, but I lose the POST data, which I need.
Using proxies means that the POST data works, but also that I get a ton of 404's, because the web page somehow now expects things to be at the root of the domain, instead of the subdomain it's at.
The trailing slash needs to be there, since without it, the same happens as when I use proxies, I get a ton of 404's for all bits and pieces of the web page.
I tried using ProxyHTMLURLMap in all shapes and forms (all found online), but none worked.
TL;DR:
I need to enable two-way traffic between myUrl.com/sprinklers/.* and localhost:port/.*, while also retaining POST data. How do I do that?
As always, ask and you shall find the answer yourself...
It turned out to be a lot simpler than I imagined. Simply telling RewriteRule to use HTTP code 307 did the trick. Apparently, this is the same as the other redirection codes, but 307 also keeps the POST data.
For those wondering how to do this in Apache:
RewriteRule ^/sprinklers$ /sprinklers/ [R=307]
That's it, fixed.
We have recently installed an SSL certificate to our fairly old version of Drupal. The front end of it works well, however, we are now unable to log in to the admin area. We put this problem on our servers who claims the website now goes into a continuous redirect look, causing the site to crash. here is what they said.
"I have taken a further look at this and we can see some pages have specific rules in place that are forcing them to use HTTP this is then causing an issue with the redirect to HTTPS, this is essentially creating a loop as the Site goes to the HTTP which gets redirected to HTTPS, which the page then redirects back to HTTP and so on. You will need to review the content of the site and to remove the redirect(s) to HTTP for any pages that have this, alternatively, we can remove the redirect to HTTPS (However this defeats the purpose of having the SSL Certificate then). Please let me know if you would like me to remove the HTTPS redirect."
The same problem can be found here at stack overflow. However, the answer is very vague considering it's a change to the .htaccess file.
Any thoughts?
put this line at the en of settings.php
$conf['https'] = TRUE;
We needed to implement SSL for our Zabbix monitoring frontend and it's caused havok on some of our backend scripting (which would be more trouble than it's worth to fix).
I'm currently working under the theory that I should be able to use some redirection magic in order to:
Access our normal Zabbix Frontend via HTTPS
Access our API via HTTP (this is the key hangup right now).
Initially - redirection was easy enough:
<VirtualHost *:80>
ServerName <servername>
RedirectMatch /zabbix/(.*) https://<servername>/zabbix/$1
</VirtualHost>
But this causes all sorts of issues with our API calls needing to still be done via HTTP (which is being done via a scripts calling API values to drive interface selections in other tools). I actually end up getting a 412 response.
So I thought I could maybe do something like this:
RedirectMatch /zabbix/(!api_jsonrpc.php)(.*) https://<servername>/zabbix/$2
While this will still let my API succeed over HTTP, it doesn't redirect my zabbix frontend to HTTPS.
This has been driving me nuts! Any help would be appreciated.
Sample URLS:
https://<servername>/zabbix/zabbix.php?action=dashboard.view
https://<servername>/zabbix/index.php
http://<servername>/zabbix/api_jsonrpc.php
Ultimately - anything that isn't "api_jsonrpc.php" needs redirected to HTTPS, and anything with that value needs to go over HTTP.
We are using Apache 2.2 and upgrading is not currently an option.
Ultimately, the issue I was having was coming down to the fact that you can't really redirect POSTs.
To resolve this, I ended up winning my argument that he library file update (forcing all traffic over HTTPS) and mass push was the only working solution and we're now golden.
You cannot negate strings just by prefixing them with an exclamation mark, lookarounds would have to be used.
I don't think API requests pass any GET parameters - try the following:
RedirectMatch /zabbix/(.*)(?<!api_jsonrpc\.php)$ https://<servername>/zabbix/$1
Got a really strange problem here. When sending post requests to my PHP script
$_SERVER['REQUEST_METHOD']
returns "GET" instead of "POST".
It works fine for every other REST method
so this is what I get
GET -> GET
POST-> GET
PUT -> PUT
DELETE -> DELETE
It only happens on one of my servers so i'm assuming it's an apache problem and i've managed to figure out that it only happens if I add "www" to my url.
I.e
www.something.com
causes the problem but
something.com
does not
I have tested on different sites on the same server and I get the same thing so I'm assuming it's global config.
Any thoughts
As the HTTP spec says for response codes 301 and 302:
Note: For historic reasons, a user agent MAY change the request method
from POST to GET for the subsequent request. If this behavior is
undesired, the 307 (Temporary Redirect) status code can be used
instead
A third (but unlikely) possibility is you're getting a 303 response to the initial URI. The solution is twofold:
Configure the clients which are under your control to POST to the canonical URI so they are not redirected at all.
Configure your server to redirect using 307 in this case instead of 301/302.
I am trying to access a secure website using this kind of url: https://securenet.someBank.com. Everything is good and I am shown the login page. Now when I just type:
http://securenet.someBank.com (i.e http instead of https) I expect to get back a page with https in the browser. (e.g when you say:http://mail.yahoo.com, you get back https://mail.yahoo.com).
But in this case https:://securenet.someBank.com just says :Page cannot be displayed.
So what did the website developer do wrong in implementing security? I am just curious. I thought this kind of thing (http --> https redirection) was handled automatically by the web server and the website developer does not even need to do anything. But apparently it is not so.
The redirections from HTTP to HTTPS are merely a convenience for the user.
As I was saying in this answer on Webmasters.SE, only the end user can check whether HTTPS is used at all, and whether it's used correctly. A MITM attacker could otherwise prevent that initial redirection from happening at all.
These automatic redirections are only useful based on the assumption that there's no MITM performing such an attack. They're useful to get the user used to seeing HTTPS on pages that should be secure, but whatever happens, it will always be up to the user to check what they're connecting to. Therefore, I wouldn't necessarily call the absence of such a redirection a developer or sysadmin mistake.
As a user, you should always bookmark and use the https:// address for sites where you expect it should be used.
[...] https://securenet.someBank.com. Everything is good and I am shown the login page.
[...]
But in this case https:://securenet.someBank.com just says :Page cannot be displayed.
Here, assuming the double :: is a typo in your question, you seem to contradict yourself. If https://securenet.someBank.com just says "Page cannot be displayed", this would be a mistake indeed.
besides the recommendation by Bruno above I would recommend you to read the following:
https://www.owasp.org/index.php/HTTP_Strict_Transport_Security
There are two things you could do:
1) Force HTTP Strict Transport Security
2) Do a permanent redirect as described in the example on that page.
Any questions, just let me know.
Fabio
#fcerullo
Probably wrong server configuration. For example in apache one must define a redirect option in httpd.conf file in order to automaticaly redirect to the https URL of the page.