Currently I have this code:
RewriteEngine On
RewriteCond %{HTTP_COOKIE} !User_is_LoggedIn=1 [NC]
RewriteRule ^ /login/ [NC,L,R=301]
The goal of the code is to make it so that any unauthenticated user can't access that part of the site without logging in, so it checks the cookie I set at login to see if it exists/is equal to 1, and then denies access via sending them to a login page if the user is not logged in. However, it is returning true/false regardless of the status of the cookie so I must be doing something wrong.
I have checked to make sure that the cookie is being set (and deleted) properly.
Figured it out. And it wasn't something that could've been fixed here either, I just mistook the actual cookie name. In my other code it was User_is_LoggedIn, but when I checked the actual cookie in the browser developer mode it was User.is.LoggedIn instead. Once I switched it the whole thing worked.
Related
I need to set up .htaccess. If the user clicks the "site.com/profile" link, I need to check if there is a "token" field in the user's cookies. If this field is not empty, I must let the user through, otherwise I redirect them to the "site.com/login" link.
You are probably looking for something like that:
RewriteEngine on
RewriteCond %{HTTP_COOKIE} !(^|;)?token=[^;]+(;|$)
RewriteRule ^ /login [R=302,L]
Obviously the rewriting module needs to be loaded into the http server. It generally is a good idea to implement such rule in the http server's host configuration. If you do not have access to that you can also use a distributed configuration file (often called ".htaccess"), but the consideration of such files needs to be enabled first and their usage comes with a number of disadvantages.
I am redirecting page using PHP header location:
Current URL in browser
https://mywebsite/open/firstpage/php/start.php?&cnt=us&language=en&url=http://secureURL.com
but want to show
https://mywebsite/open/firstpage/php/start.php?&cnt=us&language=en
I am using GET method on the other side to collect all variables. I have to hide &url in querystring but want to receive it on other side $_GET['url']
How can I share my &url without showing in URL querystring? HOw can I write htaccess?
Redirect for all URLs
RewriteEngine on
RewriteRule ^(.*) $1?%{QUERY_STRING}&url=http://secureURL.com [L]
Redirect for only /open/firstpage/php/start.php
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/open/firstpage/php/start.php
RewriteRule ^(.*) $1?%{QUERY_STRING}&url=http://secureURL.com [L]
I think this is what you want.
You can't do that. If a parameter is not present in the query string, it won't be available anywhere, it's just not there. There's no such thing as "hiding" the query string.
You could, however, use some form of session mechanism to pass a piece of data from one page to another. You could put it in the $_SESSION, or use cookies. There may also be a way to achieve this through really arcane mod_rewrite magic, but you shouldn't go down that route. Really.
More importantly: what are you trying to achieve? Why are you trying to do this?
Aesthetic reasons? Then be aware that modern browsers tend to hide the query string part of the URI from the user.
Security reasons? Then you're doing it horribly wrong, you shouldn't use something so easily manipulated by the client.
User tracking? There are established solutions out there for that (say, Google Analytics).
I want /rss-2/ to be reached at /rss/news.php (this file does not exist) /rss-2/ currently shows the feed (generated by a wp plugin), I want to show it on the other page as well.
I tried
RewriteCond %{REQUEST_URI} /rss/news.php
RewriteRule ^(.*)$ /rss-2/ [R]
but I couldn't find an appropriate flag that renders the destination instead of redirecting to it.
Wordpress looks at the url in the address bar, not how you rewrite the url. You can use the [P] flag to proxy the request, but I heard this is quite expensive since you are doing an additional request to your own server with that url. The second request will see rss-2 and will handle it accordingly, which will pass it on to request 1 which will show it to the user. Additionally, the proxy connection has to be set up for each request.
See this page for more information.
I have a .htaccess file with the following:
RewriteCond %{REQUEST_URI} !^/mobiledirectoryhere/.*$
RewriteCond %{HTTP_USER_AGENT} "android|blackberry|ipad|iphone|ipod|iemobile|opera mobile|palmos|webos|googlebot-mobile" [NC]
RewriteRule ^(.*)$ /mobiledirectoryhere/ [L,R=302]
Everything is fine and works great when viewing form a mobile phone - it detects and goes straight to the subfolder where the mobile site is located. But what I am trying to figure out is how to have a link at the bottom of the mobile site that will allow the user to view a desktop version. And when they're on the desktop version I want them to be able to get back to mobile...
Can anyone help me???
As for the "View Desktop Version" link, that should just be an HTML modification on the mobile site, huh?
In order to keep users on the desktop site after they've selected the option though, you'll need to implement a way to track their client-side preferences, e.g., a cookie. Here's some info about adding a cookie-based condition to your rewrite rule: How to do htaccess redirect based on cookie value
Yes, use a cookie. You can set them with the [CO] flag, and interrogate these through %{HTTP_COOKIE} condition, e.g. add cond to the rule
RewriteCond %{HTTP_COOKIE} !force_desktop
and detect the (un)set URIs to clear/set the cookie.
I wouldn't use cookies since that might not work properly for first-time visitors or users with cookies set to disabled. I would add a pre-defined GET-parameter that forces the site to go to the non-mobile version.
One example: If your domain is www.fancysite.com that could be www.fancysite.com/nomobile. For the "nomobile" URL you define an automatic forwarding in the .htaccess. Use the [L] condition for this rewrite rule so that other conditions are ignored. If the "nomobile" string is not present, your (already working) user agent detection kicks in and the user reaches the mobile site.
See these for some details (especially under "conditions"):
http://www.addedbytes.com/for-beginners/url-rewriting-for-beginners/
http://www.cheatography.com/davechild/cheat-sheets/mod-rewrite/
This should be a quick one... here is my current .htaccess file:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
What I need to do is make sure that if http://www.mydomain.com/cart/ is reached, it needs to force HTTPS ... so /cart/ and anything within /cart/
Once the request has been sent to http://www.mydomain.com/cart/, if there is any sensitive data in the request, it's too late. Force it to break! At least, it will give you an indication that there's something wrong with your links. More details in previous answers:
https://stackoverflow.com/a/8765067/372643
https://stackoverflow.com/a/8964190/372643
[ ... ] by the time the request reaches the server,
it's too late. If there is a MITM, he has done his attack (or part of
it) before you got the request.
The best you can do by then is to reply without any useful content. In
this case, a redirection (using 301 or 302 and the Location header)
could be appropriate. However, it may hide problems if the user (or
even you as a developer) ignores the warnings (in this case, the
browser will follow the redirection and retry the request almost
transparently).
Therefore, I would simply suggest returning a 404 status:
http://yoursite/ and https://yoursite/ are effectively two distinct sites. There is no reason to expect a 1:1 mapping of all
resources from the URI spaces from one to the other (just in the same
way as you could have a completely different hierarchy for
ftp://yoursite/).
More importantly, this is a problem that should be treated upstream: the link that led your user to this resource using http://
should be considered as broken. Don't make it work automatically.
Having a 404 status for a resource that shouldn't be there is fine. In
addition, returning an error message when there is an error is good:
it will force you (or at least remind you) as a developer that you
need to fix the page/form/link that led to this problem.
EDIT: (Example)
Let's say you have http://example.com/, the non-secure section of your site that allows the user to browse items. They're not logged in at that stage, so it's fine to do it over plain HTTP.
Now, it's cart/payment time. You want HTTPS. You send the user to https://example.com/cart/. If one of the links that sends the user to the cart part is using plain HTTP (i.e. http://example.com/cart/), it's a development mistake. It just shouldn't be there. Making the process break when you thought you were going to be sent to https://example.com/cart/ allows the developer to see it (and, once fixed, the user should never have the problem).
If it's just about the point to the HTTPS section of your site (typically, an HTTP GET via a link somewhere), it's not necessarily that big a risk.
Where automatic redirects become even more dangerous is when they hide bigger problems.
For example, you're on https://example.com/cart/creditcarddetails and you've filled in some information that should really just stay over SSL. However, the developer has made a mistake and a plain http:// link is used in the form. In addition, the developer (a user/human after all) has clicked on "don't show me this message again" in Firefox when it says "Warning: you're going from a secure page to a non-secure page" (by the way, unfortunately, Firefox warns a posteriori: it has already made the insecure request by the time it shows the user that message). Now, that GET/POST request with sensitive data is sent first to that incorrect plain http:// link and the automatic rewrites tells the browser to try the request again over https://. It looks fine because, as far as the user is concerned, this all happened in a fraction of a second. However, it's not: sensitive data was sent in clear.
Making the plain HTTP section of what should only be over HTTPS not do anything useful actually helps you see what's wrong more clearly. Since the users should never end up there anyway if the links are correctly implemented, this isn't really an issue for them.
Try adding this before the other rules (but after RewriteBase):
RewriteCond %{HTTPS} off
RewriteRule ^cart/(.*)$ https://www.mydomain.com/cart/$1 [R,L]