Is it possible to find the rough location of a user on the web without using the html5 geolocation stuff which brings up a box asking for the user's permission? I have tried MaxMind but it seems pretty poor.
Your webserver (apache or somethigng like that) gets the users IP-adress when he sends a request to your server. There are some services in the web that can tell you the country and city of that address. Google for "location from ip address" to find those services. That is the best you can do without asking the user.
Everything more accurate MUST be explicitely allowed by the user himself for legal reasons. If a user finds out that you are tracking his position without having asked him, you can go to jail!!
I've used IPlocation.net They provide a list of several providers and test them against your own IP to see if they get it correct.
I personally went with IPinfo.io
Related
For years, I've been using the email addresses MyEmail#mydomain.com and myemail#mydomain.com as if they are identical. And most of the time this is true. However now the OAuth verification process for the project seems to be failing because Google treats these as two separate identities.
The GCP project owner is MyEmail#mydomain.com. In the OAuth consent screen, I've set mydomain.com as the sole authorized domain for my app. And I use myemail#mydomain.com as my identity in Google Search Console when verifying that I am the owner of mydomain.com.
I got an email from the "The Google Cloud Trust & Safety Team", saying that the owner of the GCP project and the identity of the owner of the authorized domain do not match! The only reason for this seems to be the case of the email names, because everything else appears set up properly.
MY QUESTION: How can I change the GCP project owner from MyEmail#mydomain.com to myemail#mydomain.com?
It seems that I need to change one or the other. I would rather change the GCP owner to myemail#mydomain.com. But I can not get that to happen. I followed the instructions in Grant or Revoke Role.
I go to IAM -> Permissions - Add. I enter the email without the caps & ignore their suggestion to use the one with caps. But in the "Select a role" dropdown, it shows "Owner" as a role "Currently used". I select it anyway and click Save. But IAM -> Permissions never get changed.
I've thought of changing the owner first to someone completely different and then to the lower case email. But that might involve billing emails changing, etc.
EDIT - As a result of trying to add myemail#mydomain.com to the project, I received an email at that address from GCP, asking me to join the project. I accepted the request, but IAM is still only showing MyEmail#mydomain.com as being on the project.
Is this really the case that myemail#mydomain.com and MyEmail#mydomain.com are separate GCP identities? Might there be a different reason for Trust & Safety to think they're not the same?
If I respond to the T&S email, describing my issue, will a real person actually read it, or will the same automated test be run again to check the issue?
Resolution: I responded to the T&S email, explaining what was going on with the upper/lower case letters in my email address.
Today I got a reply: "Request Granted. Your project is now verified for ....". That's great! But I wonder if I will forever be first rejected for the same reason on all new projects that I create. It appears that the final solution is likely finding a way to change my logon email on GCP to one without capital letters.
Since you mention that you are never asked to select a different profile when logging into your account, then it should be the exact same account using the actual same GAIA ID as mentioned by DazWilkin, so there should be no difference within the GCP console between MyEmail#mydomain.com and myemail#mydomain.com.
Google usually recognizes an email address in both forms as the same account, although there are some exceptions across their products (I have had a similar experience with email addresses from Google Groups). I think this is one of those particular exceptions.
I would strongly recommend transferring the project ownership to a totally different account within your domain, then waiting a couple of hours due to Google's "propagation time" across services, and transferring the ownership back to the account using the format myemail#mydomain.com.
Now answering to:
If I respond to the T&S email, describing my issue, will a real person actually read it, or will the same automated test be run again to check the issue?
They are actually a team of people, but they tend to use a lot of canned responses, so I would definitively recommend being very specific with your choice of words when responding to their emails otherwise, you may not get a relevant response. You may also try to explain this to them via email to see if there is an actual problem with the email address or if it is just them or the system being extremely picky when checking the email address.
I think you basically have it covered. But it is important that on new Owner's account, you will need to go to "Billing" in the "hamburger" menu and either link the project to an existing billing account or set up a new Billing account to link the project.
You may also need to delete the old project owner to avoid confusion.
I'm a hobbyist student developer playing around with the Actions on Google to create a simple "text adventure" game on Google Home. Since Google Home will be speaking to the player rather than the player reading the text, I'm hoping this will create an experience similar to the "Dungeons and Dragons" roleplaying game, with the computer working as the "Dungeon Master." With the natural language assistance offered by API.AI and Actions on Google, it seemed like a good fit, since the player can respond "naturally." Here's an example of an Amazon Alexa skill that does essentially what I'm going for.
However, every time I boot up the game, it's always a new game. I'd like to store a savegame with the user's previous state in a JSON file hosted on the user's Google Drive -- Since I'm just a student doing this for fun, I don't actually have an official website or anything beyond a free Heroku server I'm running the app from, making storing saves on my end pretty much out of the question.
I've walked through the Google Drive REST quickstart for Node.js, and I've gotten that working in the console just fine. The only problem is in that quickstart, the user has to click a link to authorize the application to read the stuff in their Google Drive account, and I'm not sure how I'd be able to "click a link" and give back an access token via voice on Google Home.
Is there a way to do this via Google Drive? Or is there a better way to provide persistent data between sessions? I don't normally work in web development, so any help would be appreciated.
The bad news is you won't be able to get away from the need for a user to use his web browser to authorise your app to access his Drive.
The good news is that you only need to do this once. When your app requests authoirsation, it should specify "offline", which will result in you being given a refresh token. You should save this somewhere in your database of users. Whenever you need to access the user's Drive, you can use the saved refresh token to request an access token and you're good to go.
You have a few problems that you need to solve here, and while they seem related, they're not as related as you might hope:
You need to get authorization to access a user's Drive space
You need to authenticate the user's Home (so you know this person has come back)
You have to connect the two relationships - so you know what Drive space to use for the Home device that is talking to you
You've found the answers to (1) already, and as noted, you'll need to use a browser for them to authorize you to access their Drive. You'll then store the refresh token and will be able to access it in the future.
But that is only part of the problem. Home does not provide you access to the user's Google account directly, so you'll have to manage your own account mechanism and tie it to Home. There are a few solutions here:
Home provides anonymous user identity in the JSON sent to your webhook. You can access this using getUser().user_id if you're using the Actions API library, or access this in the data.user.user_id field in the JSON. While this is similar to a browser cookie, it only stores the user ID and can't store additional data. There is also no concept of "local storage". On the plus side, this ID is consistent across devices.
You can request user information such as their name and address. But it doesn't have anything unique or account information, so this probably isn't useful to you.
You can implement an OAuth2 server and do account linking. Note that this is the other side from what you need to do with Google Drive - you'll be providing the access and refresh tokens to authenticate and authorize access to your account and the Google Home device will send these tokens back to you so you can determine who the user is. You don't actually need to store account information - you can provide token information using JSON Web Tokens (JWT) or other methods and have them store account information in a secure way. Users will use the Google Home app to actually sign-in to your service as a one-time event.
In order to handle (3), you may be thinking that (1) lets you get tokens and the OAuth solution for (2) requires you to hand out tokens. Can the two be combined? Well... probably, but it isn't as straightforward. You can't just give the Google OAuth2 endpoints to Home - they explicitly block that and you need to control your OAuth2 endpoints. You may, however, be able to build proxy endpoints - but I haven't explored the security implications of doing so.
I think you're on the right track - using Drive is a good place to store users' information. Using Home's account linking gives you a place where they have to come to your web site to authenticate and authorize their Home, and you can use this to do the same for their Drive.
First I apologize if I'm a dolt and am missing something obvious, but I've spent a few hours scouring documentation and am lost.
I'm trying to write a python script that will upload a bunch of images to a single user's Google Drive. The user already exists and will never change. I am not writing a web app and don't plan to use any user interface whatsoever. Everything will be done through code.
As best I can understand from the Google documentation, I have two choices:
1) Write a web app and register it to use the Drive DSK. This of course requires having urls and such for the web app.
2) Create a service account, which ties my "app" to a new service account email.
Neither of these options works for me. Is there any way to simply log in to a single user account and access their drive through python scripting?
There is a deprecated API called ClientLogin that would enable you to use the username and password for a login to access that Drive data.
But the basic idea is that you should be using something more secure -- from your users' point of view -- that allows them to authorize you without giving you their password.
For your use case it is possible that the user is you or someone you know and that you are accessing their account through a more personal kind of authorization. In that case, ClientLogin may be your best choice. If this is an application designed to be used by arbitrary users, the deprecation of ClientLogin is for a good reason and I would urge you to bite the bullet and choose one of the supported options.
The correct solution is to separate the authorization phase from the access phase. The authorization process needs to be run one time only, and can be done from a simple web site. The result of this is a refresh token which is analogous to a username/password. You will need to be aware of the security implications. Make sure you only grant drive.file scope to minimise the impact of a security breach.
Since you are uploading images, you might also want to look at the picassa api.
I apologize for asking this here instead of Google's forums, but I find that they tend to yield no results at all, ever.
I have a domain verified on Google Apps through HTML file upload, which I am currently using for email.
I don't recall exactly how I prompted the verifications, but I got prompted for one about a week ago for another address#mydomain.com, and I'm trying to find out how I can void the verifications through HTML, so I can switch to the newer method of creating a DNS record.
And finally, is there a way an individual can void unauthorized verifications through Google? For example if someone verified a domain you currently own at an earlier point in time? Google doesn't allow any support contact for normal Apps accounts.
Thank you for any assistance.
Trying to verify the account or the domain?
What do you see when you go into the control panel?
If you use HTML validation and then change the IP of your web server you might get requested to re-validate.
Best use DNS validation.
Good luck.
This is somewhat of a newbie question I'm sure and I hope the community will excuse me for not knowing this (or not knowing the appropriate search terms to resolve my question).
So, this is the deal: I'm running a small webpage with a small amount of visitors. I've written the whole page in HTML and CSS myself and I host it in my private DropBox (http://dl.dropbox.com/u/3394117/Hemsida/Psykofil/Index.html).
I've bought the domain name "www.psykofil.org" from Loopia (www.loopia.se) and I've directed this domain to the index.html file referenced to above.
Now, this is what I want to happen: I have three different places you can go to on the page (you choose where to ge through a menu on the left). When one of these links is clicked, it takes the user to another .html-file. What I would like to happen here is that this is seen in the adress field so when he or she clicks on "x", it should say www.psykofil.org/x on top. Also, when he or she navigates away from the webpage through a hyperlink I would like the adress field to update to show the new location. Right now, no matter what the user does, it always says www.psykofil.org in the adress field.
I probably should mention that my options (freely translated from swedish) when I go to the configuration of my domain name at Loopia is the following:
DNS
Parking
Forwarding (the one I'm currently using)
Send to an external URL
(Unavailable because I don't have a web hotel with Loopia) Point to another domain in the account.
(Unavailable because I don't have a web hotel with Loopia) Own homefolder for webpage.
That's because your page is inside a <frameset>, so the address bar will never update.
You say "I've directed this domain to the index.html file referenced to above." It sounds like you've set up 'domain forwarding.' Framesets are often the 'trick' hosts use to keep the same URL - embedding the pages you're 'forwarding' to in a frameset. It's called "domain masking." See http://www.hostingmultipledomainnames.com/domainforwarding.htm for a description of how it works.
If you upload your actual html files to your site root, that should do the trick. If you're not sure how to do that and you're a new webmaster, you may want to be in touch with your web host's support. Otherwise, if you want to have that domain, but keep your files in your dropbox account, your options I believe get complicated (things like reverse proxies).
UPDATED:
Typically, when people create a website, they do three thing: register a domain, buy a web hosting account, and then associate their domain with their hosting account. You've done the first part, and have found a clever way of managing the second part, but you haven't done the third part.
The process is like this:
You register your domain. I.e., you pay $10-30 a year for the exclusive right to a given domain name. Registering the domain means that when people type 'http://mysite.com' into their browser, your domain will come up. However, it's just a placeholder - there isn't any real content there. All your files and images need to be uploaded to a server in order for people to see them.
You purchase a web hosting account. Or in your case, you upload your files to a publicly-accessible server, which has the advantage of being free. You then upload all your content.
This is the part you're missing. You now need to associate your domain name with your hosting account. This typically happens without your intervention when you purchase both your domain name and your web hosting account through one company.
However, if you acquire them separately, you need to do two things:
a. Log in to your domain registrar and point the domain name to your server for your web hosting account. This is a signal to the Internet - hey, when you type in the domain name 'http://ssss.com', go to this server.
b. Log in to your web hosting account and "park" the domain at your account. This may be hard to understand at first, but basically, just telling the Internet to go to this or that server when typing in your domain name isn't very useful.
If that's all we needed to do, I could just register http://my-amazon.com and point my domain to Amazon.com. Then people could surf Amazon.com as http://myamazon.com and I could get rich from selling this now incredibly popular domain.
But that doesn't work. In order for me to actually browse the web hosting account through my domain name, I need to "add" the domain name to my hosting account. Dropbox doesn't let you do that. It's a file-sharing system, which you've cleverly used as a web host. However, you'll never be able to log into Dropbox and park your domain there, because that's not what they do.
Summary: You can think of this process like a pass in basketball. You can throw the ball by sending the user to a server, but the server has to catch it. In order to catch the ball, the server needs to know it's coming.
Your domain registrar is 'faking' this process by adding one page to its own server, which links to "http://dl.dropbox.com/yourpage/etc/etc/Index.html". This way, your domain registrar doesn't have to worry about hosting all your content and the headaches of technical support and server space.
The downside is, you don't have a webhost that allows you to park a domain at the moment. The upside is you're saving about $60-100 per year (it might be more or less in Sweden), which is what a basic "shared" hosting account would cost.
You can decide if having distinct webpages (http://psykofil.org/contact.html" etc), is worth it for you, or whether you're fine for now with the very low-cost solution that isn't perfect but at least allows people to access your site. What you've come up with is actually pretty cool, but it does have some limitations.
Finally: If you do want to go ahead an buy server space so you can host your site, it will be less of a headache to buy it through Loopla, if the price and service are good. Typically, you are given the option when making the purchase of linking your account to your already-registered domain name. Then all you need to do is use an FTP program like Filezilla to upload your content to your account, and you're done.
It seems your host is "masking" the URL, meaning actual index.html page located at "www.psykofil.org" is in fact, loading your index page located via dropbox into an "iframe" , hence your main URL does not change to reflect the changes.
Solution: Upload your file to your main host and change the default index file that has iframes with the dropbox index file.
I believe it's because you're using frames. Were you to simply link to the other html page(i.e About page) then the address bar would update.