I have a server with many cPanel accounts - some, but not all, have apps that require Google Map API keys (like store finders or geoloaction for real estate locations)
So far I have been setting up different keys for each project and all seem to be working ok (most are small sites with limited visitation so I don't think usage will be a problem)
Now I am trying to troubleshoot a problem and no matter what I try to set up a new key for it it won't work
I'm starting to think I may have been better to set up just one authenticated key for my servers IP address and generate one server key and one browser key and then authenticate each domain that wants to use it via cName or whatever
Can anyone advise the best path here
Related
I need to use the Google Places API through PHP in a Wordpress site hosted on Flywheel.
It seems the option I need to use is the IP addresses (web servers, cron jobs, etc.).
My problem is that flywheel has a dynamic IP address system and after a couple of days the API stops working since the IP has changed.
I' trying to see if I can authenticate the site using something else but I have not been able to find it.
I've looked at googleapis/google-api-php-client but the Places API is not part of the APIs the package can connect.
Do you know how If there is any other way to whitelist a site for a web server with a dynamic IP?
It's not necessary to use the API key restriction. You don't need to restrict it by an IP address. It's an optional feature per key.
I'll try to give you at least an option/suggestion because I'm not sure how you intent to use the Google Place API but you can basically create 2 separate keys:
One public API key for browser based calls (show map, suggestions, etc..). In this case I would use HTTP referrer for as restriction and add your websites where this key is running.
One private API key for server based calls (server2server, queue, cronjobs, etc..). Since you have a floating IP you would need to know the full range. In this case I would not "additionally" restrict it by the IP address and only use the secret.
Another suggestions in case your really really want to restrict this additionally:
Ask flywheel if they can give you a dedicated IP address. A quick google lookup showed some forums which indicate that they support it. Attention: I'm sure they will charge you for this additional money.
Move your cronjobs, queues, ... away from flywheel and host it somewhere, where you have control of the IP address. (e.g. AWS EC3 t3.nano with an elastic ip address - costs you ~$5/month)
Hope this helps and gives you some impressions about your options. Let me know if this answers your question or if you need and further information.
Using Google's Directory API to create users, I'm now running into an issue where the user is asked what city they usually sign in from.
This is a problem because the webserver used to create the account via the API is in a different location than the users are logging in from for the first time. This hasn't happened before and it's suddenly happening now (no code change).
Has anyone ran into this, and is there a way to mitigate it?
For the record, I'm using a PHP implementation, if it matters.
Edit: Clarification that the webserver in another location is the webserver used to create the Google account via the API.
See Google's FAQ on suspicious logins. I'd recommend setting a strong initial password for these users that is 8+ characters in length and contains upper and lowercase as well as numbers or punctuation.
Assume there are two different apps on appengine- one powered by Go and another by PHP
They each need to be able to make specific requests to eachother, purely over the backend network (i.e. these are the only services that need to make these specific requests- other remote requests should be blocked).
What is the best-practices way of doing this? Off the top of my head, here are 3 possible solutions and why I am a bit worried about them
1) Do not keep them as separate apps, but rather modules
The problem with this is that using modules introduces some other annoyances- such as difficulties with Channel Presence reporting. Also, conceptually, these 2 requests are really the only places they touch and it will be clearer to see what's going on in terms of database usage etc. if they are separated. But the presence issue is more of a show-stopper
2) Append the request with some hardcoded long secret key and only allow response if via SSL
It seems a bit strange to rely on this, since the key would never change... theoretically the only way it could be known is if an administrator on the account or someone with the source revealed it... but I don't know, just seems strange
3) Only allow via certain IP ranges (maybe combined with #2)
This just seems iffy, can the IP ranges be definitively known?
4) Pub/Sub
So it seems AppEngine allows a pub/sub mechanism- but that doesn't really fit my use case since I want to get the response right away - not via a postback once the subscriber processes it
All of them
-- As a side point, assuming it is some sort of https request, is this done using the Socket API for each language?
HTTPS is of course an excellent idea in general (not just for communication between two GAE apps).
But, for the specific use case, I would recommend relying on the X-Appengine-Inbound-Appid request header: App Engine's infrastructure ensures that this cannot be set on requests not coming from GAE apps, and, for requests that do come from GAE apps (via a url-fetch that doesn't follow redirects), the header is set to the app-id.
This is documented for Go at https://cloud.google.com/appengine/docs/go/urlfetch/ , for PHP at https://cloud.google.com/appengine/docs/php/urlfetch/ (and it's just the same for Java and Python, by the way).
purely over the backend network
Only allow via certain IP ranges
These requirement are difficult to impossible to fulfill with app engine infrastructure because you're not in control of the physical network routes. From the app engine FAQ:
App Engine does not currently provide a way to map static IP addresses to an application. In order to optimize the network path between an end user and an App Engine application, end users on different ISPs or geographic locations might use different IP addresses to access the same App Engine application.
Therefore always assume your communication happens over the open network and never assume anything about IPs.
Append the request with some hardcoded long secret key
The hard coded long secret does not provide any added security, only obscurity.
only allow response if via SSL
This is a better idea; encrypt all of your internal traffic with a strong algorithm. For example, ECDHE-RSA or ECDHE-ECDSA if available.
I have to build a login in the website which will be bind to a system.
e.g. A user can login only through the machine he has registered.
I will not be able to get the mac id or any other unique identifier through PHP which I can bind with that login.
I have hosted the website on shared hosting, So I cannot install any new library. Standard libraries are available.
Let me know if there are best possible ways to do the same.
There is no unique id of the machine, at all. MAC addresses don't transition network boundaries, IP addresses are not unique and volatile. Beyond that you only have what you get in the HTTP headers, which is not unique or permanent either.
The best you can do is set a non-expiring cookie on the machine with a unique id and depend on that; i.e. make your own id. That'll create problems when the user switches browsers or machines or just cleans the cookie storage though, so make sure you have a procedure in place for this case. Cookies may also be hijacked, so prepare a procedure for this case too and transact everything over SSL secured connections to minimize the likelihood of that occurring.
In short: everything depending on the physical machine of the user is problematic on the web, since the web is explicitly designed to be client-agnostic. Machine ids cannot be depended upon for security. Registering a machine using a unique cookie can be a useful part in strengthening traditional username/password security, but it's not a replacement.
The best is typically to base your security on traditional usernames/passwords (+ second factor authentication if possible), and use the unique cookie as additional tool. For example, every time the user logs in from an unknown machine, you require an email/SMS feedback loop to "register" the machine.
I have a webserver with a drupal 7 installed on.
Many primary domains are pointing to this webserver (es domain1.com, domain2.com) and each domain is see the same website.
But if i log in into one (domain1.com) when i visit the domain2.com i'm not logged in.
I know that is a domain cookie problem, but there is a way to generate the cookie for a list of domain when i register/log in?
Hope that someone can help me
Here my module developed for getting a SSO system working with Drupal and Domain Acces.
https://github.com/andreacavattoni/DomainSSO
This is the very good question and have done small research on your question on different ways:
OAuth:
After reading the documentation and gone through many service providers it is not possible. Oauth service provider gives the consumer key and secret and they check the request coming from the domain and thus if the same oAuth consumer key is used on different domain Names that doesn't work.
Setting Cookie Multiple domains
Simply, it is not possible to set the cookie without visiting the domain by any means
Thus, I can say that it is not possible to set cookie or use the same consumer key and secret for multiple domains
Alternative ways
Use HTML5 Web Storage for storing the information and then accessing
the information from different domains is possible.
Use AJAX/CURL for sending the request for setting the cookie for different domains such as example.com/session_cookie.php?info=xxxxx
Maintain a single sub-domain/page for all the domain for login purpose for across all the domains.
I think you may want to look at Bakery
Could be of interest: Stack Exchange Blog: Global Network Auto-Login (using HTML5's local storage)