I have seen some sites use hostnames as data such as usernames (for example username.example.com) and was wondering how you would be able to achieve this.
Is it good practice to use hostnames like this or are there reasons against it?
Thanks in advance.
It is generally bad practice to treat hostnames this way. Lookups become a bit more complicated and it is always safest to use usernames in the path or query.
Hostnames are designed to be thought of in a global sense. For instance user.example.com/username/profile
It also helps protect the user (a little) because paths can be encoded into the http request where a subdomain request essentially requests user.example.com and that request can be redirected multiple times before returning to the client and dns monitoring is the number one way that people do tracking.
DNS tracking is easy because its already fast, open, and the contents aren't designed to be hidden like https or more recent ipsec techniques.
I've accomplished this by setting up a DNS wildcard with your DNS host (*.example.com) then using PHP to parse out the username in the URL and act accordingly.
Related
I'm working on a site which shows different products for different countries. The current url scheme I'm using is "index.php?country=US" for the main page, and "product.php?country=US&id=1234" to show a product from an specific country.
I'm planning now to implement url rewrite to use cleaner urls. The idea would be using each country as subdomain, and product id as a page. Something like this:
us.example.com/1234 -> product.php?country=US&id=1234
I have full control of my dns records and web server, and currently have set a * A record to point to my IP in order to receive *.example.com requests. This seems to work ok.
Now my question is what other things I'd need to take care of. Is it right to assume that just adding a .htaccess would be enough to handle all requests? Do I need to add VirtualHost to each subdomain I use as well? Would anything else be needed or avoided as well?
I'm basically trying to figure out what the simplest and correct way of designing this would be best.
The data you need to process the country is already in the request URL (from the hostname). Moving this to a GET variable introduces additional complications (how do you deal with POSTs).
You don't need seperate vhosts unless the domains have different SSL certs.
I would like a concrete example in an answer if possible.
For explanations sake we have three players here.
My Server (myserver.com)
Client Server (myclient.com)
Client User (accessing data through myclient.com)
I'm making a web service available to my clients that allows them to retrieve their data in JSON format. In order for their websites to work they have to use the standard XOR workarounds - either making the request server-side or relying on me to set
Access-Control-Allow-Origin: http://myclient.com
So two part question here. First, why do I set the origin policy at myserver.com? Why does my server care who it serves content up to? Shouldn't it be myclient.com that sets this? Concrete example here would be great.
Part two, I understand that JSONP works around this, but I'm worried about using it because I don't understand the security implications from part one. What is the point of JSONP if I can just set Access-Control-Allow-Origin: *?
Lots of questions!
JSONP is definitely dangerous if you intend to serve user-specific content. If the content the server is serving is completely public, and (probably) read-only, JSONP is a wise choice. Don't use it for anything that assumes a 'logged in state' or authentication/authorization.
CORS is definitely much better than JSONP, but it's not supported in every (older) browser. If you want to support as much as possible, you will need some kind of fallback. CORS allows you to do requests other than GET, which greatly improves flexibility.
The reason the target server needs to allow this, is mainly because javascript running on domain A, should not be able to access domain B. If domain A could 'allow' this, it implies you could create javascript applications that have access to the sandbox of any public server. Only the owner of domain B can explicitly allow the owner of domain A to access their content.
Your argument (why does domain B care who accesses their resources) would normally be valid. But this is not to protect domain B, it is to protect the end-user. Domain A should not be allowed to perform requests on behalf of the end-user to Domain B without explicit permission.
And just to be sure: unless you understand the security implications of JSONP quite well, CORS is likely a much safer choice.
I run this site and I approve access for a section of the site for people. I only want to approve static ips. If i have a bunch of IPs how do I find out if they are static or not? I can do the remaining parts but there is probably some function in the socket library or something that lets me script the part to find if the users are using static or dynamic IP.
thanks !
Php/Js would work too.
There is no way to inherently tell if an IP address is static or dynamically assigned. Based on the hostname that the IPs resolve to, you could probably make a guess as to whether they are static or not, but there is nothing definitive to facilitate this.
You could use the socket module to resolve the IPs to hostnames and flag them as "static" or "dynamic" based on some kind of "best guess" algorithm, but it would be only that: a best guess.
Here is an example using a random Verizon FiOS IP address. This assumes that any IP starting with "pool" is dynamically assigned.
>>> hostname = socket.gethostbyaddr('71.243.222.111')[0]
>>> if 'pool' in hostname:
... print hostname, 'is dynamic'
...
pool-71-243-222-111.lsanca.fios.verizon.net is dynamic
You're going to have a very tough time determining all of the various naming conventions and this would in no way be a complete solution.
You might want to ask yourself what kind of problem you're trying to solve first, and whether filtering access by IP address is providing the kind of verification you need.
I'd use a pragmatic solution: New accounts have a trial phase of a few days. After that they can only log in from the same IP used to sign up. If they still have that same IP it's most likely static.
Well, you don't have a problem, do you? If they ask for access from IP X, you give them access from IP X. If it turns out that it was dynamic and they switch, they no longer have access. In practice, no access from dynamic IPs :)
Seriously though, the authority on IP assignment type is the host from which the user is accessing. Thus, you need to ask the user what it says in his/her config.
Here's my situation.
I register myweb.ca (country specific) domain with Webhost Provider A because they allow ccTLD, while Webhost Provider B does not. I host my PHP files on Webhost Provider B at http://mysecretweb.com/myweb/ because I like them better (reliable, cheaper, proven etc...).
I want to achieve the following:
When user types http://myweb.ca/aboutus.html, they will see the contents of http://mysecretweb.com/myweb/aboutus.html
When user visits aboutus.html, the browser must display http://myweb.ca/aboutus.html, NOT http://mysecretweb.com/myweb/aboutus.html
The public and search engines CAN NOT BE AWARE of the domain http://mysecretweb.com/myweb because it is a secret.
Any solution offered must not negatively impact SEO
Will domain forwarding with masking solve my problem? Any suggestions?
Additional Detail
Someone suggested I change nameserver information from ns1.providerA.com to ns1.providerB.com. Someone else counter argued that provider B will prohibit this because provider A is not on the network, and that provider B may ban my account for doing this. I am confused...
You could write one PHP script that gets an URL from $_GET, downloads it and passes to user (including headers) - and then some .htaccess Rewrite magic to point everything to that script. This is about the only way that is entirely transparent to both humans and bots.
you could try and detect bots and humans apart and have diferent actions for the 2
I want http://mynewdomain.com to forward with masking to http://mysecretdomain.com/mynewsite. When a user types in http://mynewdomain.com/aboutus.html, he should see the contents of http://mysecretdomain.com/mynewsite/aboutus.html.
I do not want the public to be aware of http://mysecretdomain.com.
Will the way I use forwarding and masking negatively affect SEO?
By using domain forward and masking, is there any danger of people becoming aware of mysecretdomain.com? (ie. will users discover the relationship between mynewdomain.com and mysecretdomain.com?)
Additional details
It is extremely important that no one discover the http://mysecretdomain.com/mynewsite domain and directory despite the fact that it is hosting all the content. Do I have to do anything to ensure this?
Why not just map your secret domain to the ~/www directory on your host, and the new domain to ~/www/newdomain? Then when you go to mysecretdomain.com/newdomain/ it looks in ~/www/newdomain/... exactly what you described, with no redirects.
Maybe I don't understand your goal here.