I have changed the domain address from olddomain.com to newdomain.com and redirected everything 1:1. I see that the 301 redirects don't pass any referrer page in the server logs for the new domain. Is this normal? If not, how do I fix it?
Thanks!
Related
I need some clarifications about multi-domain authentication. I have a site, e.g. www.example.com, which uses sys_folder id = 25 which has own users and groups. And now I created another domain using site configuration, www.example.com/mycompany, which uses another sys_folder id = 50. Both have felogin with different storage folders. It is correctly working in login failures. But when I logged in my main website, say www.example.com. It automatically logged-in on other domain www.example.com/mycompany, which shows my fe_users details. How could I handle authentication separately for domain-wise? Does TYPO3 support that?
This is a general issue and not really related to TYPO3: when you log in to www.example.com, the cookie path will be /. It cannot be anything else since it would then be limited to that path.
Thus when you enter a sub-site like www.example.com/mycompany, the cookie of www.example.com is sent since /mycompany is covered by the / path. See Set-Cookie: Wildcard "Path" for details.
The proper solution here can only be to separate sites using subdomains instead, e.g. mycompany.example.com and www.example.com. Then each site will have its domain stored in the cookie which ensures only the correct cookie per site is used.
Notice that in this case the main site must be something like www.example.com and not just example.com, otherwise the same issue will show up: a login cookie created on example.com will be sent for mycompany.example.com and all other subdomains.
I have a page on my website with a button that clicks into another page on the same website. This page on-load redirects to an external URL.
What will be the IP address that the external site will see when the redirect happens? Will it be my website's IP, or will it be the user's IP?
It will be the client's (AKA user's) IP address that the external website will log. However, since you're redirecting from your website, they will also receive a Referer header header; which will point to your website's address.
The Referer request header contains the address of the previous web
page from which a link to the currently requested page was followed.
The Referer header allows servers to identify where people are
visiting them from and may use that data for analytics, logging, or
optimized caching, for example.
In NGINX is there a way to detect is a site was accessed via a 301 redirect? An NGINX server was setup incorrectly and site B now has some 301 redirects cached in browsers pointing to site A. I would like to redirect these a second time to new site C from both A and B, but, only redirect from A if they were previously redirected from B to A and let users who directly access A get to A without redirect.
I hope this makes sense.
You can't detect that, no.
Browsers do not include HTTP status codes from previous responses in a new request. At most you get the previous URL in the Refererer header, but even that is unreliable (many users disable sending that header as it is seen as a security or privacy breach).
As such an HTTP server has no way of knowing if a request was initiated by a redirect, the user following a link
For reasons only my past self knows I put a 301 redirect in place to force all traffic to example.org from www.example.org. Put simply it dropped the www. subdomain.
Now I would like to change it so that all traffic goes to the www. subdomain, which would be problematic as any cached 301s in user's browsers would send the user into a redirect loop.
So I am planning on buying an SSL certificate and encrypting all traffic on the site - for other reasons too. If I redirect the users to https://www.example.org/ will it still cause the browser to look at it's cache and go into a redirect loop again?
To my mind https://www.example.org is a different URL to http://www.example.org, but do all the browsers see it this way for caching purposes?
Will previous 301 redirect still be cached if site switches to using SSL?
I can't really answer if they will be in practice. However, I can say they should not be. An origin consists of a scheme, domain and port (some hand waiving). HTTP to HTTPS changes the scheme or protocol, so it should be as different as foo.com and bar.com.
See Same-origin policy on Wikipedia for more detailed examples.
How do I detect whether a web page in a UIWebView needs to use HTTP or HTTPS? I have an address bar where the user can type in "www.apple.com" and then I convert this to a NSString with http:// in front of it. If Apple.com requires HTTPS though, how would this be handled? What exactly should I do? Thanks for your help!
In most cases, a web site that requires HTTPS is set up to automatically redirect to the correct SSL port. In generally goes like this:
Enter the URL http://www.mysite.com/ in your web browser. Because there is no port specified, it attempts to use the default port of 80 for HTTP.
The site receives the request on port 80 and determines that you need to be using SSL, so it sends a redirect response back to the browser. That redirect response usually tells your browser to try again using HTTPS on the standard HTTPS port (443).
Your browser re-initiates the request to the HTTPS port.
So, in the vast majority of cases, you don't need to know whether or not HTTPS is required or not. Just go to the site using http. If it requires HTTPS it will almost always redirect you there automatically.