I'm creating a wordpress site that needs to have two distinct versions. The changes in the two are only frontend, and will be very minimal so I don't want to create two separate sites.
Instead, I'd like to pass a query string along that dictates whether or not to serve the prop version.
People will access the prop site by going to http://example.com/?prop=1. Once they're there, I need that "prop=1" to be carried over when they click any link on the blog. I could do this by hand in all of the templates, taking all the links and making sure to append that query to them, but I'd like to do it in an automated way.
Basically, if that query var is there, carry it through to any links that person clicks on the site. If it's not, then serve regular links. I'm also open to using session variables, but someone should be able to visit the prop and regular sites at the same time in separate windows, so I'm not sure if that will work.
Your can try this solution - htaccess rewrite
or a redirect plug-in
basic idea will be using RewriteCond %{HTTP_REFERER}
The address of the page (if any) which referred the user agent to the current page. This is set by the user agent. Not all user agents will set this, and some provide the ability to modify HTTP_REFERER as a feature. In short, it cannot really be trusted. - php.net
http://www.php.net/manual/en/reserved.variables.server.php
if the current request has ?prop=1 then it will append ?prop=1 to the end , else nothing happens.
once user enters ?prop=1 mode they won't be able to leave it unless ?prop=1 is removed
Related
I have a website that serves up various information for users who have accounts on it by accessing information listed under a username and a category. Using the variable names, u and c, the url looks like this:
www.originalwebsite.com/user.php?u=username&c=43
I want a user-defined custom domain to remove any evidence of a username variable or variable name. Other variables (like category) are fine to remain. Ideally, this would result in the following link pointing to the one included before:
www.customdomain.com/c=43
My reasons being that the custom domain would be unique for the user and, therefore, would be remove the need to specify the user (in theory, not in practice so far) as well as presenting the site from a custom domain in a manner that looks like a single site, rather than the portal like options of the original.
I can get www.customdomain.com/u=username&c=43 to work but am trying to think of the best method to remove reference to the username when using the custom domain (both the variable identifier and the variable itself). I'm struggling to think of how I'll inform the original website of what user account to use if it's not mentioned in the url itself.
At the moment my best idea is to let user.php handle this with a condition of whether the request is from originalwebsite.com or a custom domain. If finds that it's the latter, it checks it against a database listing and finds the relevant user settings discreetly. This feels like quite a slow procedure, however.
If my example is not clear, think of sites like Tumblr, where you can add a custom domain and, from that point on, urls make no reference of your user name.
From some discussion here and further research, it seems as though there's no quickfire way of doing this. It looks like I'm stuck with either keeping some form of reference that can identify a username in the url, using a cookie or sticking with my original idea of referencing the custom domain against a database to find the appropriate user and settings.
I've gone with the database referencing option as I need to remove references to any username from the url and I can't always rely on cookies. I need a 100% success rate of correct redirection.
I've changed my user.php file to check if the request has come from originaldomain.com or newdomain.com. If it's from originaldomain.com, it looks for a username variable in the url as it should have one for any user that doesn't have a custom domain. If it comes from a different domain, it checks to see if this domain is listed in the database and finds the user from this. There's a few catches that I'll need to trial but I've got 90% of the issue solved.
I want to create a private url as
http://domain.com/content.php?secret_token=XXXXX
Then, only visitors who have the exact URL (e.g. received by email) can see the page. We check the $_GET['secret_token'] before displaying the content.
My problem is that if by any chance search bots find the URL, they will simply index it and the URL will be public. Is there a practical method to avoid bot visits and subsequent index?
Possible But Unfavorable Methods:
Login system (e.g. by php session): But I do not want to offer user login.
Password-protected folder: The problem is as above.
Using Robots.txt: Many search engine bots do not respect it.
What you are talking about is security through obscurity. Its never a good idea. If you must, I would offer these thoughts:
Make the link expire
Lock the link to the C or D class of IPs that it was accessed from the first time
Have the page challenge the user with something like a logic question before forwarding to the real page with a time sensitive token (2 step process), and if the challenge fails send a 404 back so the crawler stops.
Try generating a 5-6 alphanumeric password and attach along with the email, so eventhough robots spider it , they need password to access the page. (Just an extra added safety measure)
If there is no link to it (including that the folder has no index
view), the robot won't find it
You could return a 404, if the token is wrong: This way, a robot (and who else doesn't have the token) will think, there is no such page
As long as you don't link to it, no spider will pick it up. And, since you don't want any password protection, the link is going to work for everyone. Consider disabling the secret key after it is used.
you only need to tell the search engines not to index /content.php, and search engines that honor robots.txt wont index any pages that start with /content.php.
Leaving the link unpublished will be ok in most circumstances...
...However, I will warn you that the prevalence of browser toolbars (Google and Yahoo come to mind) change the game. One company I worked for had pages from their intranet indexed in Google. You could search for the page, and a few results came up, but you couldn't access them unless you were inside our firewall or VPN'd in.
We figured the only way those links got propagated to Google had to be through the toolbar. (If anyone else has a better explanation, I'd love to hear it...) I've been out of that company a while now, so I don't know if they ever figured out definitively what happened there.
I know, strange but true...
Background: I have a website, which we'll call AwesomeSite.com; it handles all of my traffic. Additionally, for the purposes of marketing I have a second domain, which we'll call PromoForAwesomeSite.com; it redirects all traffic straight to AwesomeSite. Both sites are built using PHP, MySQL, and Apache.
Problem: I want to serve up different content to users based on how they came to my site. Specifically, I want to show promos if the user was redirected from PromoForAwesomeSite.
Question: How can I detect that a user came from PromoForAwesomeSite and thus create a different session state for them?
p.s. I am well aware of the shortcomings of this approach, in that once a session cookie is deleted promo users cannot see the promo content unless they revisit the redirect site (not likely). Unfortunately, this cannot be helped.
You can utilize the $_SERVER['HTTP_REFERER'] and see if contains the PromoForAwesomeSite.com in the referrer string. For instance something like this:
session_start();
if(substr_count($_SERVER['HTTP_REFERER'] , 'PromoForAwesomeSite.com')){
$_SESSION['from_promo'] = 1;
}
As referrers can be blocked by the browsers, so you might look into the possibility of sending a GET param in the redirect string from the promo site. Not sure how you are redirecting from your promo site but if its PHP you can do something like this , if not you will get the idea what I mean :)
HEADER('Location: http://AwesomeSite.com/index.php?from=promo');
So instead of (or in additional to) checking the referrer you can also check for this string and save in the session.
In your case the referrer won't be carried on if you do an automatic redirect at the landing time. Thus, If I were you, I would handle it like this:
1. On PromoForAwesomeSite.com
header('Location: http://www.awesomesite.com/promo.php');
2. On AwesomeSite.com
a. Create a promo.php gateway page
b. On the gateway page
setcookie('Promo', '1', time()+(5 * (24 * 3600))); // five days promotion cookie - adjust it
header('Location: http://www.awesomesite.com/index.php');
c. On the index.php
if($_COOKIE['Promo']){
// show promotion
}
This way you will solve the issue with the session as well.
I have an interesting problem to solve here that may require some creative direction. I have a PHP page which has a variety of different page outcomes depending upon which value is passed through the web browser. For example:
http://examplesite.com/landingpage.php?id=one
http://examplesite.com/landingpage.php?id=two
http://examplesite.com/landingpage.php?id=three
With the current set-up, each of these pages has a different offer for the site visitor. Here is the catch...
I only want the page available to the visitor once per session.
That seems like it would be easy enough, but I cannot make it work right. I have used a one-time offer script to submit a cookie which then re-directs the user to another page if they have already viewed the offer, but that did not work for this situation. It will work fine for one landing page, but it is based on the root PHP page so if any of the other values are passed it will re-route the user even though they have not seen the offer.
For example, if a site visitor goes to:
http://examplesite.com/landingpage.php?id=one
they will see the one-time offer. Then, if they go to:
http://examplesite.com/landingpage.php?id=two
They will be re-routed as if they had seen the offer for 'two' which they had not.
I hope this issue makes sense. If you need further clarification, just ask. Thank you for going through my problem and if you don't have the exact answer, but can point me in the right direction it would be much appreciated.
Without looking at the code for landingpage.php, I can only guess that you are not factoring in the id when you check for the existence of the cookie. You need to set cookies on a per-id basis. Otherwise the behavior you see will occur: viewing id=one will set a cookie and when the user views id=two, landingpage.php sees the cookie exists and redirects the user.
If you want to keep it simple enough, you can just have your cookie be a string of id fields delimited with a character such as a pipe or comma: viewed_ids=one,two,three. Then you could parse this to see if the id of the current page is in the list of viewed ids and redirect the user if it is, or add it if it isn't.
I am sure you realize that maintaining state in the session can be easily worked around by the user, since you mentioned you only need this redirection to occur on a 'per-session' basis.
Ok, firstly this is not about forms this is about consistent layout as a user explores a site.
let me explain:
If we imagine a (non-ajax) digital camera online store, say someone was on the DSLR section and specified to view the cameras in Gallery mode and order by price. They then click onto the Compact camera's page. It would be in the users interests if the 'views' they selected we're carried over to this new page.
Now, i'd say use a session - am i wrong?
are there performance issues i should be aware of for a few small session vars ( ie view=1 , orderby=price) ?
Speaking of performances, there should not be much problems with either solutions.
Some things that have to be considered are :
With GET, if an URL gets copy-pasted (in a email or MSN), the other who will receive the URL will have the same GET parameters
is that a good thing, or not ?
On the other hand, session will not be shared, if an URL is copy-pasted
which means the first guy will say to the other "key, look at this", and the second guy will not see the same page ;; same thing with bookmarking, should I add.
GET is specific to each URL
While SESSION is shared accross all tabs of the user
Which means browsing with several tabs at the same time can cause troubles, when using Session, if you don't take care of that
I'd say use both. Store it in the session, but also put it in the get parameters for the page.
Why? This way the user is able to carry his options from page to page, but they are also in the URL so if he sends search results to his friend, his friend sees them the exact same way he did.
No, the session's performance will not degrade by putting those small variables in there. Unless you're storing monolithic arrays in your session, the vast majority of the time loading a session will be reading it from its storage medium (file, database, memcache, etc).
You should use GET in your case.
There is one simple rule in the web development: each page with different content must have it's own address. So, customer can save any page into favorites, send it to a frend. It's pain in the bottom then someone sends you a link to a particular page saying "Look!" but site uses frames and you land at the front page and dunno where to look.
You can save user's preferences into his profile/cookie (not session), but it should be reflected in the address bar as well.
Sessions being used for completely different purpose, shopping cart is an example.
It's a subjective question, it would work either way.
Personally I would go with sessions as it doesn't interfere with the URL so people can bookmark the url if they wanted.
However the argument for that would be if they bookmarked it they might see different things if it was done using $_SESSION.