Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm building the frontend marketing website for a web application. The frontend is WordPress on one server and the app is on another. We will set a cookie for users who are already customers. For returning customers, when they go to, they should go to the web app. For new visitors without the cookie, when they go to to, they should go to the WordPress site. How do I do this?

The web app is probably on nginx, but possibly apache. The WordPress will probably be on apache. I'm wondering if I use DNS, nginx, htaccess, or PHP to determine how to send visitors to one server vs. the other.

share|improve this question
I guess using php or some other scripting language to catch all requests, read the cookie, and redirect to either would be the simplest solution. You could also proxy the sites but I guess you're likely to run into all sorts of problems. I wouldn't go for your idea. Running them side by side for a while with different URL's would save your customers quite some confusion! – Louis Somers Oct 8 '12 at 23:05
You are approaching this problem from a software perspective (i.e. a cookie) rather than using standard infrastructure to handle the request. – Brent Pabst Oct 9 '12 at 13:28
up vote 1 down vote accepted

In general using cookies to store things like this is a BAD idea. What if your users don't allow cookies or they clear them? Do they have to know or will they have an idea as to where they should go to access your application?

The better solution is this:

  1. Setup two different DNS entries, one for and another for
  2. On your primary website (www) include a quick and easy link on the page to redirect to the application.

Users who are "smart" will bookmark the applications login page once they get there if they really want to remember it. It simply doesn't make sense to try and handle this sort of logic and validation on your end since you can never be 100% sure is and who is not a customer of yours.

share|improve this answer
"What if your users don't allow cookies […]?" — what's your estimate of such a probability, BTW? How many sites you see nowadays which would work just fine w/o using cookies? As to me, it's not an argument at all. – poige Oct 9 '12 at 15:23
From a simple web search that number is about 10% that disable cookies and/or JS. The point of modern web design is to be unobtrusive, this design by the OP is OBTRUSIVE! – Brent Pabst Oct 9 '12 at 15:35
I wouldn't care. Those who turn cookies off should know what they're doing. – poige Oct 9 '12 at 15:56
Those who don't have cookies set would expect to re-login anyway, so at 10%, that is a pretty minor issue, so the cookie approach is fine. – Joe Fletcher Oct 9 '12 at 16:54
There's a difference between a persistent logon token and a cookie to simply handle redirection. You didn't mention any of that in your initial post. If that's the case there should be NO way for your front-end to decipher or read that cookie as only your application should have the proper encryption key to then read the token. – Brent Pabst Oct 9 '12 at 17:21

Typically, the web server would front the application. The application would exist on a path different from the site root, for instance It is also possible to use a different domain name for the application. This provides some isolation of the application from the Internet. The web server can also serve up static content for the application such as graphic, javascript, and CSS files.

WordPress on Apache handles this quite well. I have a variety of non-WordPress content in paths mixed with a WordPress site.

Consider using the Apache security plugins to edit the requests being passed back to the application. It is also a good idea to limit the URLS being passed back to the application.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.