I am working on an android application that needs to search for events in different calendars from a service account.
The calendars have been shared with the service account and I can access each one with "Calendar.get (" calendar.id) ", but I would like to be able to list all the calendars shared with this account without needing to know the specific ID of each one .
Investigating I found that by default calendars shared to a service account are not added directly to Calendarlist, so "Calendarlist.list ()" returns an empty object "[]".
Is there any method to list all shared calendars?
If you want to list the calendars that have been shared with a service account (via CalendarList: list), you should first insert the corresponding calendars individually via CalendarList: insert.
This, of course, requires knowing the id for each of these calendars. There's no other way around it.
If your application workflow allows it, I'd recommend calling CalendarList: insert as part of the sharing process of each calendar.
Alternative: domain-wide delegation:
Also, if the point of using a service account is to avoid user interaction, you could grant it domain-wide authority and use it to impersonate a regular account instead (the account with which the calendars would be shared). This way, calendars would be added to CalendarList without having to call CalendarList: insert.
Related answer:
Gsuite resources can't be shared with service account
Related
I want to know what will happen to the users of my app that I used anonymous sign in method for them.
The Firebase documentation is really BAD and didn't explain everything and expect developer to find out himself.
I found in its old version documentation that anonymous session will expires based on the expiration time has been set in Login & Auth tab, but even there didn't mention this means just the session ends or it means that user id will remove also from my app users list or what EXACTLY happened?
I found this answer but it really is not acceptable. The number of anonymous users will grow very very fast if you do a web app and make every thing hard.
I even cannot see the number of my app users in my dashboard!!!!!
So, what should i do? should i develop a dashboard for my data myself or Firebase team should do it? At least for managing users i should have more power than just searching user with their email and when you use custom login you cannot do this also.
Anonymous users don't expire, and there isn't currently any automated way to purge them.
Firebase doesn't automatically remove them because it doesn't really know if a user is still storing data linked to that login - only the app creator does. Imagine if you are playing a puzzle game on your phone, and get to level 100. Then when you go to play level 101 next year, all progress is lost. Firebase can't just assume a user being inactive for a year means that the account can be removed.
There is a couple tools that should help, though.
1) Admin SDK & Firebase CLI list users.
2) Linking multiple auth providers
3) Auth State Persistence
Once you list your users, you can check that each doesn't have any other providers, and hasn't been used recently, doesn't have data stored, and delete them.
Better, though, would be to ensure that only one account is created per user. If you create an anonymous account to help users store data before logging in, you may want to consider prompting them to link a auth provider (like Google or email). If you link the account, rather than creating a new one, you'll avoid abandoned accounts from active users.
In general, you will also want to make sure to use auth state persistence to ensure that there aren't more accounts than necessary being created. Creating 1 account per new visitor, rather than 1 per time someone repeatedly visits your page, will significantly help keep user growth in check.
In my case, I am using the anonymous sign-in method for authentication without the knowledge of the user.
Each time when the user leaves the app, delete the anonymous user by -
FirebaseAuth.getinstance().currentuser?.delete()
There will be no stacking up of anonymous user with this and limits the number of anonymous user in the app
2023 update
Firebase has automatic clean up now.
If you've upgraded your project to Firebase
Authentication with Identity Platform, you can enable automatic
clean-up in the Firebase console. When you enable this feature you
allow, Firebase to automatically delete anonymous accounts older than
30 days. In projects with automatic clean-up enabled, anonymous
authentication will not count toward usage limits or billing quotas.
Any anonymous accounts created after enabling automatic clean-up might
be automatically deleted any time after 30 days post-creation.
Anonymous accounts created before enabling automatic clean-up will be
eligible for automatic deletion starting 30 days after enabling
automatic clean-up. If you turn automatic clean-up off, any anonymous
accounts scheduled to be deleted will remain scheduled to be deleted.
These accounts do not count toward usage limits or billing quotas. If
you "upgrade" an anonymous account by linking it to any sign-in
method, the account will not get automatically deleted. If you want to
see how many users will be affected before you enable this feature,
and you've upgraded your project to Firebase Authentication with
Identity Platform, you can filter by is_anon in Cloud Logging.
Docs
There is a possible cloud function for that.
Check: delete-unused-accounts-cron
This function deletes unused accounts after a certain time. Which might be also helpfull for nonanonymous users.
If you only want to delete anonymous users or check only for them (for example delete after a different inactive time than normal users) you can identify them by checking:
const inactiveUsers = result.users.filter(
user => {
isAnonymous = user.providerData.length == 0;
//do something when anonymous
});
If you'd like anonymous users to be removed from your user list, you'll have to write a service to do that for you.
Since firebase doesn't provide a way to list registered users, you'll have to make sure you're storing some sort of user list in the database. You can then use the node.js admin sdk to get user data, check if the user is anonymous, and find when the user was created. For performance reasons, you may wish to store this information in a special area of your database and retrieve it all at once. Once you've identified a stale anonymous user they can be easily deleted.
I have a saas platform I'm building and I'm currently struggling with how to model my auth flow. The system is going to be multiple multi-tenant applications but I would like to unify user authorization & authentication. Basically, each US State will have its own web app/resource server/database and every county in that state will be a separate tenant. I cannot combine all states into one application, so that is not an option.
I would like to throw all users and their information/password into one database connected to my auth service. But each county (tenant) admin within each state (web app) needs to be able to add & manager their users and their roles. So the auth service needs to be aware of all the different tenants across each application. I also need to be able to link items created in each database to the user that created it. If I create object "X" and another user in my county views that item, they can see "Kovaci" created this.
I also do NOT want SSO between states but if possible I would like users to be a part of multiple tenants within one app (not a requirement though). Native iOS/Mobile apps are another client I need to support with this flow.
I used this bitoftech article to base off of: http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/comment-page-1/#comments
And here is my paint quick mockup: multi saas design
My question is just generally how do I design this auth part? Can I store all users in one auth db like my goal? If so, how do tenant admins manage them and how do I link tables in my separate app db's to the users' current info in the auth db?
In Meteor, how can I proceed with LoginWithService (or LinkWithService) and get the service data without actually creating an account?
In my app, I use the service API keys to do certain tasks, to do that I use LinkWithService()
But I also allow users to login/create accounts with LoginWithService() function. But these two functions conflict with each other because if an account already exists with password + service, it will force a log out followed by another log-in.
I'm not sure if that made sense, anyhow I would like to just get the login service data without actually creating an account. How can I do this?
I'd like to show some map layer on my webpage, so I decided to give a try to this Google service. As the data is collected in a database in my server, I chose to use a service account as explained here and then use the private key generated in my php script.
Everything works fine when creating a table and inserting some test values. I get the table Id and I'm able to play with it from my script. The problem is that I don't know how to access these table from the web browser. In my API console usage stats are shown fine, but when logging with my account to Google Drive I don't see any table in there.
Where am I supposed to access them if at all possible? Do either the apps.googleusercontent.com or developer.gserviceaccount.com accounts play any role to log into some other service to get access through web?
I also got an api key associated, but when trying to query a table I get a 401 error.
Any hint? I'm feeling a bit lost now. Thanks.
You are using a Service Account right?
So when you create a table with this account, this account will be the table owner. No one else has permission to see this table.
When you access the Fusion Tables web interface with Your Personal Account, you will only see tables that you createdwith your Personal Account.
If you wish to inspect the tables created with your Service Account, you have to use the Google Drive API with your Service Account credentials to give access permission to your Personal Account.
Also if you wish to make your table (or any other type of document) public, you need to use this Google Drive API again.
See more about the topic here:
https://developers.google.com/drive/v2/reference/permissions/insert
Tip: if you want to achieve something on behalf of your Service Account that you only need once (so no need to implement a logic for it in your webapp) I'd seriously advise you to consider using the OAuth2 Playground. You can set your Service Account credentials in the "Settings" and issue authorized requests on behalf of your Service Account. Very usefull tool, no coding needed.
What is the best way to manage domain specific services? For eg: In a Financial domain, Should I have a global service "AccountCreation" or "CheckingAccountCreation", "CreditcardAccountreation" etc.
I am struggling whether to keep them at global level or keep them at the product level. what is the best approach?
You should probably focus in the data first: what data is there, and what data needs to stay consistent. Then focus on what the behaviours around that data are.
In a Financial domain, Should I have a global service "AccountCreation" or "CheckingAccountCreation", "CreditcardAccountreation" etc.
In this example, I would say that you have an "account" service, because you clearly have some accounts - and you probably have to ensure that, eg, you don't duplicate account numbers, apply anti-fraud rules, manage the workflow of creation, etc.
Your examples identify some behaviours: create a checking account, create a credit card account. Those would appropriately be commands that you send to the service, because they result in mutation of the data that the service owns.
If you add a "customer" service, though, that would be distinct from the accounts service: it doesn't have to be consistent with the account service, just to have a reference from accounts to customers by ID.
You also generally don't have shared behaviour that touches both parts - updating data about a customer shouldn't touch the details of their accounts (directly), and updating an account doesn't change the details of a customer.
You might have business rules in one service that change another, such as the account service listening for "a customer became a student" announced by the customer service, and then doing some internal processing.