We allow our users to connect their Google Analytics account to our CMS. However, many of them choose to have us manage their GA, so we have a lot of properties.
Each property has its own View ID, and when we connect the View ID, we do so by entering the View ID. Then, the account select prompt shows up. We select the account that owns the property (which is usually the same account, say admin#company.com), and then retrieve access and refresh token.
This all works well. Except, sometimes it seems the refresh token invalidates.
Is this because of the refresh token limit (we definitely manage more than 25 clients)?
If so, what would be a better way to connect the property to the site, while still allowing users to use their own GA account if they wish to do so?
I was thinking of trying to retrieve which google account is being use for the connect, but I am not sure how I would do that.
Any ideas?
I figured it out. The refresh token limit is per actual google account, took me a while to figure that out. I now store a default value in the main DB and if that one can access the ID that is to be connected, the default is used. Otherwise it will redirect to the Google auth window and authenticate normally.
Related
I have a web site in google cloud. I use Identity-Aware Proxy (IAP) to protect it.
When a request comes in IAP checks if I'm authorized and then responds with either
if I'm authorized: the response from the resource I requested
if not: a 302 or 401 response depending on if it thinks it is an ajax call or not
Now I want to use Google Sign-In for Websites on top of this.
This might seem redundant since I am already logged in by the time I would see the buttons but I want to use it as a way to log out or change user account.
Now what I have tried to do is:
var auth2 = gapi.auth2.init({
client_id: 'mykey.apps.googleusercontent.com',
})
auth2.isSignedIn.get()
// false, I was hoping that I could somehow piggyback on my existing session
auth2.signIn()
// shows a pop up, allowing me to select an account
auth2.isSignedIn.get()
// true
currentUser.getBasicProfile()
// works
This seems to work except it shows me a login box even when I'm already logged in which is suspicious.
Add to this that when I do
auth2.disconnect()
auth2.isSignedIn.get()
// false
and then do a full refresh then I still get my resources from IAP proving that I'm still logged in there.
Questions:
How can I get this to work?
Is this even the correct way to do it?
I don't know much about Sign-In for Websites, but there's another option that might work for you. Have you considered adding a link to /_gcp_iap/clear_login_cookie to provide a "change user account" option? (It's documented here: https://cloud.google.com/iap/docs/special-urls-howto )
If the user is logged in with multiple Google accounts, that will bounce them back to the account picker. Today, if they're only logged in with one account, it will just send them right back into the application -- but there's an enhancement rolling out next week which will display the account picker even for the single-account case, giving the user a chance to sign in with an additional account.
Hope that helps!
--Matthew, IAP engineering lead
This is not SEO related but somewhat merely client related.
There is a website in particular that uses Google Analytics tracking to uniquely identify each one of their users.
This website has a blocking system that is preventing me from viewing some of their content, which I'd like to view.
I figured out that the website uses the Google Analytics cookie to somehow identify me.
Is there a way I can somehow spoof the client-ID from Google Analytics to basically make a new identity for myself? Thanks community.
GA has two ids that could identify a user, clientId and userId. The client id is set by the javascript tracking code. To delete that you would simply have to delete the _ga cookie. You will get a new ID randomly generated that does not identify you other than in the sense that multiple pageviews with that clientId will be treated as coming from the same user.
The userId is set by the server when a user logs in (to connect all sessions of that user, however it must not personally identify the user in question), so at that point the website already has to know you to set a userid.
It seems more than unlikely (and technologically not even feasible) to use Google Analytics to limit access to a website. For starters, Google provides an opt-out plugin for Analytics that would make such a system rather ineffectual, and I'm not quite sure how such a system would work.
To yet answer your question, you can change the clientId by manipulating the _ga cookie and replace the value therein, and you could spoof the userID e.g. by using a browser plugin that allows you to manipulate http requests. However I don't think this will let you bypass any access protection.
Is it possible to disable authenticated user in timely matter like trial version for a certain days or hours? Is it possible to do it programmatically? If i'm not mistaken, I can't find a settings within Firebase Authentication Console..
When you hover over a use in the Firebase Auth panel of the Firebase Console, you can see an overflow menu. That menu contains the option to disable the user's account:
This will prevent the user from logging in in the future. It will not immediately disable their access to the app, since their current access token may still be valid for up to an hour. If you want to immediately prevent the user from accessing your app, you'll also want to implement a secondary authorization mechanism, such as keeping a list of banned users in the Firebase Database.
I have created an Appcelerator iPhone app based on Firebase authentication, which works very well. But now I come across some unexpected behaviour.
My setup is as follows: on app start, the user must login or register. During registration, the account is created, and the corresponding account data (uid, name, email, date etc.) is also stored in a /users/uid data entry.
When I remove a user from Firebase through the Dashboard, by removing it from both /users/uid and the "Login & Auth" tab, it looks all clear. But when the user opens the app, he still remains logged in.
How can I enforce removing a user, where he is also logged out the next time he opens the app?
According to the Firebase Google Group, this is a known bug with Firebase:
This is a known bug on our end. As you noted, after deleting a user,
existing auth tokens are still valid and can be used to read and write
to your Firebase database. Security Rules are still enforced on these
tokens and that user will still only be able to access their own
Firebase data (if your rules are set up as such). Those auth tokens
will be valid until they expire. There is currently no workaround for
this bug although we are going to be fixing this in a future release.
https://groups.google.com/d/msg/firebase-talk/Yr_wn02q0bk/eTM9hop3paoJ
The only thing I can think to do is check whether you can read to your users area, and if there's nothing there, force a log out.
From your behavior it seems like there maybe a configuration issue or just a bug. Does the users information get removed from corresponding data-source (DB or in-memory store)? I would start there then move on to researching how the corresponding cookies/tokens work and contact their support.
Though perhaps you shouldn't out right delete the user, perhaps just disable the user therefore, accomplishing the same result? Maybe this behavior will work properly.
I want to build a custom asp.net control to put on a webpage that will allow people to see a piece of information from my facebook account that requires auth. For the sake of simplicity let's just say I'd like it to display the last thing that I liked. I don't want the visitor to my site to have to be logged into facebook (nor would they have to be my friend on fb). I want my site to somehow store a token that I have authorized and then it will use this token for the access. I know this can be done initially, but I'm confused what happens when the token expires. Or for that matter if I log out from facebook. Is there some type of token or secret or something that I can request that can be auto-renewed again and again by my website independent of any login state that I have as an fb user? Does this require me creating an fb app and associating the token to it?
I don't have any code at this point, I'm looking for a higher level of guidance on the protocol that should be used here, from there I can hopefully figure out the code from existing samples, docs, etc. This is my first code interaction with facebook so don't assume that I know very much at this point :-)
EDIT: I've been reading everything I can about this topic and I can't seem to find a solution. In the past there was an RSS feed but that appears to be gone now. Then there was also the offline_access permission which is no longer available. This seems like such a simple task but I'm just not able to connect the dots. I have been able to get the initial user token with perms for reading "likes", that's easy. Now I can store that in my website's db and use it to make requests for that data anytime someone loads my page. But eventually the token will expire and I'm not seeing any automatic way to renew it that wouldn't potentially involve user "Larry", who happens to be browsing my website, being asked to supply MY facebook credentials. Basically it seems as though I could never log out from facebook or I'd be risking a broken feed on my website. Is the fb auth model just not set up to allow for thist? To summarize again - a user Bob wants to give his permission to acme.com to always be able to display Bob's most recent like regardless of whether Bob is logged in to fb or not. He would only want to have this stop working if he revoked authorization to the WhatDoesBobLike app which runs on acme.com. Possible?
-JT
You would need an extended access token. It will only last up to 60 days and from then you would need to re-extend.
If it were a page you could extend the user access token then grab the page access token which would never expire.
Read more at
http://developers.facebook.com/roadmap/offline-access-removal/