Is there some way to only require "insert" access to a user's Google calendar?
There's a scope: "https://www.googleapis.com/auth/calendar.events" that gives my app complete read/write access to all calendar events for a user, but that seems over-reaching, and likely to make my user's distrust the actions of my app.
The min permissions to insert events into a user calendar is read/write access.
There are 4 permissions level:
See events (no events details)
Read (can see event details)
Write (can see, create, edit and delete events)
Owner (can manage the properties over the calendar)
Owner permission is much intrusive, I recommend you use writer permission level as a min permission to create events.
Edited
Since there is no current "write only" scope in google calendar api when we require manage events for our application one strategy could be the next:
You create a Google account "foo.calendar#gmail.com".
You grant access from this "foo.calendar" account to your application with "write" scope permission.
Now, each user of your application must create a new "Calendar" and share it with "foo.calendar#gmail.com" and the min permission "writer" as soon as we want create events for our application.
This is the "less intrusive" way for your application over the user data. Now you can create all events in this shared calendar that must be exclusive for your application events. Important: The user should not mix his private events with the application events in this shared calendar.
If your application will work with a lot of users and each user will have their own event over his own calendar, then your application must store somehow the calendar of each user.
Table user_calendar:
id_user: user id
id_calendar: google calendar shared with you
foo: some of foo
bar: a lot of bar
Related
In my web app I need to add freebusy read permission for my service account to the primary calendar of gmail addresses provided by users.
How do I do that?
Delegate domain-wide authority to your service account
From your domain’s Admin console, go to Main menu menu > Security > Access and data control > API controls.
In the Domain wide delegation pane, select Manage Domain Wide Delegation.
Click Add new.
In the Client ID field, enter the client ID obtained from the service account creation steps above.
In the OAuth Scopes field, enter a comma-delimited list of the scopes required for your application. Use the scope https://www.googleapis.com/auth/calendar for full access to the Google Calendar API.
Click Authorize.
I am currently writing an online-booking-module and I want to store events (beside in the database) in a owned google-calendar (this calendar is then added to the responsible employee in outlook).
My idea was just to give the API my auth-data and the calendar-id and then being able to insert and delete events.
The calendar must be private, not public!
Now I see it is more designed to access user's calenders getting their permission etc...
Answer:
Yes, you can authenticate the application as yourself and add the events to a private calendar owned by you.
More Information:
Once the application has been published and contains your credentials and token, there will be no issue running the Events add Calendar API method as you, regardless of who runs the program.
Other option:
Alternatively, you could create a Service account to impersonate your account and run the calendar API queries, though you would need to provide the Service Account with access to your private Google Calendar.
References:
Google Calendar API - Events: insert
Authorizing Requests to the Google Calendar API
Google Developer Admin Console
Google Cloud - Service Accounts
Understanding Service Accounts
Creating and Managing Service Accounts
Creating and Managing Service Account Keys
Granting Roles to Service Accounts
I am something of a Google Analyitcs novice.
I have a PHP website that allows client to add their website names in order to advertise for services. When they add a website they own they have to validate it by allowing my server to login to their google analytics via the standard OAUTH permission screen etc, find their property and read their number of visits for the last month. The authorisation is stored in a session access token as $_SESSION['access_token'], which is then lost as soon as the session is closed or the user cleans out their browser. I think Google calls this a "web server application".
The problem is I would now like to run a cron every day on my server that accesses the google analytics of each of these customers who have authorised me and downloads the last days visitor numbers in order to be able to display them on the website. The problem I have is obviously I cannot be asking for the users OAUTH permission because it is occuring every day and without the user being present.
1) Would this new use case that does not require OAUTH and the users presence if they have already previously authorised me be a different type of application? What google analytics calls a "Service application"?
2) If it were a different type of application such as "service application" would I be able to loginto these accounts to pull the readonly data already authorised in the previous OAUTH web application, without requiring any further user input. Basically do the authorisations previously granted transfer over to a different type of application if I limit myself to using the same email address and using only the readonly properties I was granted access to?
I would appreciate any pointers or help - thanks.
So in the end I solved this by setting up OAUTH for a web app and then using refresh tokens to avoid having to ask for authorisation each time.
We're about to implement processing Google Analytics report data in a web application.
Is there a "consent window way" to grant access rather than having to manually generate access tokens and configuring access to report views?
Google analytics data is private user data. In order to access a users data you must have their permission. To gain the permission of a user you request their consent to your application accessing their data.
To do this we use Oauth2 there is no other way to access a users data you are going to have to request consent of the user. Oauth2 always shows a constant screen to the user the first time
I am developing an app for my college and there are different types of users called students ,teachers , hod's
etc. When they login, how do I know a teacher logged in, or a student logged in? Is there any function in firestore for role based signups and signins?
I was thinking that when a teacher signs up, I will add a tag end of her uid.username that if username is 'DANIEL' while signup, I will add a tea for teachers and stu for students at the end of the name what they provided.
So when they login i will get the uid and do the string manupulations and get the last three letters so that i can know who logged in so that i can show different UI to Different types of users
Is there any best way to do like this ?
while singning up user enters his username example:"daniel"
i will update that username in uid.username like this "daniel-stu"(if student signed up),"daniel-tea" if techer signsup.
Storing this information in the user's display name can work. You can read it back from there next time, and take action in your application's client-side code. But note that this means that any user can change their role, since they can also call the same code to update their profile. If that is not a concern for your app, then this approach sounds like it would work.
If malicious users should not be able to change their role, then you shouldn't set that role from the client-side application code. In that case, you can set the role from a server (or your development machine, or Cloud Functions) using the Admin SDK. Since the Admin SDK runs in a trusted environment, it has expanded privileges and can update the profile of any user. So the Admin SDK could update the display name of the user in the same way you have in mind.
But this still isn't secure, since you're still setting a property that anyone can modify for their own profile. Again... if that is no problem for your app that is fine, but if the use-case requires that you can rely on the property to be correct, we have to keep looking elsewhere.
The Admin SDK can set additional so-called claims on a user profile that client-side code can't modify. Such claims are for things that affect the permissions of the user, such if the user is an admin, or what role/group your users belong to. This sounds quite close to what you are describing, so can also be used. And this time, only your code that runs in a trusted environment will be able to do so.
Finally, you could store the additional information about a user in the database. It's quite common to have a collection (Users or Profiles) in the database, where you store a document for each user (with the document name being User.uid). You create the document when the user first signs in, and update whenever you need to. You can do this from the client-side code (if there is no need to control what gets written), or from code that runs in a trusted environment (such as your development machine, a server you control, or Cloud Functions) if you do need to keep control. A big advantage of this approach is that all users can potentially see the information in this collection, where the client-side Authentication SDK only allows a user to read their own user profile.
For more on this, see:
Adding new data to firebase users (in which I essentially list the same options with fewer words)
Add extra User Information with firebase (store the information in the realtime database)
Associate Firebase Users to Database Records (also using the realtime database for the additional information)
Cloud Firestore saving additional user data
this video explaining custom claims
and many more previous questions on this topic