I'm trying to detect the CNAME used on incoming traffic so I can customize a site accordingly. I have a site that displays some info to the client (actually more complicated, but will work for an example). Some of my customers send their own customers to my site to see this info. They are using a CNAME to get to my site. I would like to display certain logos etc to the viewer based on what CNAME was used to get to my page.
What I have come up with so far is using dns_get_record, I'm I on the right track with that if it can be done at all?
Thanks for any help!
It depends on the language that your web content is written in, it also depends on what webserver you are using. What you want to look for in the web content is the "HOST header". If you want to treat it differently at the web server then what you want to look for is "virtual hosts".
Related
I have a hybrid WordPress plugin that fetches all data using curl from the main server. Let's call it A.
B is the client that requests for data and also can send data to A.
Now every request is encrypted and authenticated using a API access keys.
But the problem here is if I copy the plugin from B to a new client site C, the moment I use the same access keys etc. the plugin starts working.
I want to be able to restrict the access of one API access key to one domain name. How can I attain that?
I'd say to include the allowed host's IP address (B) in your access key administration.
So: when B does a call, you can validate the key and the IP it's calling from.
On A, you can use something like $_SERVER['REMOTE_ADDR'] to test the IP calling the script.
Two downsides: when sites move servers, the plugin will stop working. And of course, people can still spoof their IP, so there is a way to get around this, but at least you make it a lot more complicated and probably not worth the hassle for most cases.
A suggestion by TJHX
Make it part of the license you give your customers. The honest ones will follow it, the dishonest ones will find a way to break your DRM. This is a problem technology can't really solve confidently, especially when with things like wordpress people can just see your code - By TJHX
I have also looked into a lot of options but the mere fact is that the user always has access to the code in the wordpress plugin and can easily make amendments to the CURL request Headers even if you encrypt it.
All we can do it add it in our Licenses.
In my plugin, there are iframes that will be loading the data on the frontend so I am going to accept the domain name when the user buys the plugin and will check the referrers to my iframe to sort this issue out.
Thanks a lot guys for your help.
Use Case: I am working on an application where user can build his own html template and publish it to his domain by selecting one. He can use different components to do this.
Issue: I want to transfer the pages build by the user from my domain to his created domain. Something similar to what is done here. Now currently in the prototye, what I do is write the content to a file (a .html file using ajax request) then make an FTP connection to the users domain (possible beacuse domains are created dynamically by the application) and transfer the files to his domain.
This, I believe, cannot be the right way and I would like to build it around a REST service which would make it flexible and also secure.
Research: I went through the web and found some website handle this very well (like the one mentioned above) and believe they have built it as a service. Am I on the ?
I would like suggestions and the possibilities so I can move forward. I am using PHP on the server side and javascript on the client side.
I can see some possible features to add safety to your services :
Check the source IP from the request, and only allow your servers to make the REST calls.
add header('Access-Control-Allow-Origin: *'); with the list of the possible domains to make the calls, instead of the *.
add security tokens related to the caller machine IP address, that would work as a password for the machine.
send all the data using post instead of get.
To update the page, I would go this way :
keep the data in the database, on server 1
add a page that reads from the database the content of the page based on a domain parameter
on the domain page call server 1 with the domain parameter to get the contents
I'm building a product that involves clients adding their FB app data into my product's dashboard.
In this case each client would have to go to developers.facebook.com/apps and create an app first.
I would want to have a button which says "Create App" in my website that when clicked, would create the app instantly for the client.
So is it possible to create a FB App from my website (with script, not manually) ??
Thanks in advance,
Altin.
It was possible couple of years ago, and now it's been removed.
First of all, I’d think about the question, “does every client really need their own app?”
Maybe it’d also be possible to have all of the stuff you’re planning to do (no details on that) under one app, and have it decide on what data to show based on the fact which client’s Facebook page it gets added to (if it’ll run as page tab app), or by some additional parameter passed to it when calling it. You could f.e. example automatically redirect to a sub-folder on your webspace based on this criteria, that displays individual pages for that client.
If that’s not an option, then yes, your clients will have to set up the basic app themselves (and therefor they’ll need a verified account) – and afterwards tell app id and secret to you. Many of the “advanced” app settings can then be set by you via script – look at what properties are marked as “(Editable via API)” here: https://developers.facebook.com/docs/reference/api/application/
(Although some of the basic settings, like category, description, logo etc. will still have to be set by your client themselves. But other, more “technical” stuff, that the client maybe doesn’t know about and doesn’t even want to be bothered with, like canvas/page tab URLs etc. can be set by you. I’d say that’s as good a compromise as you can get for such a scenario.)
I am working on a website application where it is necessary to know the location of a user when he/she posts. What would be the best method, using PHP, to determine where (general location) the user is posting from? I know you can use the user's ip with various services offered, but I am looking for something that works with users using our mobile site as well.
maybe use the browsers inbult geolocation tools? eg:
http://www.digimantra.com/howto/current-location-iphone-safari-firefox-browser/
then just parse the javascript info into your php variables?
Most sites use Accept-Language request header with $_SERVER['HTTP_ACCEPT_LANGUAGE']. If request IP also matches the language, you can be pretty sure it's the right country.
There are libraries that you can use to lookup the users location via their IP Address like http://www.geoplugin.com/webservices/php
I've managed to develop some code in php which would use a mobile template instead of the default one, however I'm not sure if I should redirect to a mobile URL (such as /mobile/) or if it's ok to just have the mobile template showing up instead of the default.
Any thoughts on this?
This is up to you.
Some sites put there mobile view on its own domain, e.g., m.yourdomain.com or yourdomain.mobi, and if a mobile user arrives at your non-mobile site (and are detected via agent-string) they'll be redirected to the mobile domain.
However, Tim Berner-Lee states:
It is fundamentally useful to be able
to quote the URI for some information
and then look up that URI in an
entirely different context. For
example, I may want to look up a
restaurant on my laptop, bookmark it,
and then, when I only have my phone,
check the bookmark to have a look at
the evening menu. Or, my travel agent
may send me a pointer to my itinerary
for a business trip. I may view the
itinerary from my office on a large
screen and want to see the map, or I
may view it at the airport from my
phone when all I want is the gate
number.
There's something to that. This seems to prefer a non-redirection approach but, instead, detecting the agent type and displaying the appropriate view.
Which approach is better is up for debate.
You could combine the approaches by having your main site respond with views based on agent type while also placing content in a mobile-specific domain (not duplicating it, just mapping the additional domain to it), which will allow phones that don't send a mobile user agent string to view the lighter mobile site.
Both approaches are equally valid. Just make sure, for usability sake, that you give the user that ability to switch between the two views and make it sticky. That way, someone on their iPad doesn't always get the mobile template and someone who gets a url to the mobile site can switch back on their desktop.