I would like to know if AWS Cognito offers any facility where I can configure to disable a confirmed user if the user hasn't logged in for, say 60 days.
One way I thought of doing this is to keep track of the user's last logged-in date and calculate if it exceeds 60 days. If yes, then disable the account by using AdminDisableUserCommand from the SDK.
But before I do this I want to know if AWS offers any out-of-the-box solution to disable users who haven't logged-in for a while.
I saw the following link which talks about deleting an unverified user.
How to delete a AWS Cognito user automatically after certain time
But as my case slightly differs of actually disabling a confirmed user, I feel there might be some out-of-the-box solution provided where I do not have to rely on a Lambda trigger.
Is this possible?
Related
I am new to Shopify and exploring options to run a streaming service. I want to build functionality through which I am able to limit the number of users concurrently login through a particular account.
That is if say 4 users are logged in through user A it should not allow 5th user at the same time (Based on plan) as people share their login credentials. Does Shopify provide this functionality or any good recommendation of any such app?
You can check this app . This is solving similar problem not sure how they are doing it though .
You can configure this app easily and set your custom banner for 5th user (In your case) or also force log out the first user in case of 5th user attempts to login.
I am working on a web application which is based on Google App Engine (GAE). The requirement of the application is that one user can be associated with multiple company accounts.
My application has two main types of accounts. One is that main Admin/Company account. Other is the employee account (i.e. the persons who work under a company). Now, what I want to do is that to allow an employee to work under more than one companies, but he does not have to make a separate account for each company. His single account can be associated with multiple companies.
I have explored different platforms which are already supporting this feature. The major ones which I found are Slack and Asana. And my problem can be perfectly mapped to what Slack is doing right now i.e. I create a single account on Slack and I can join multiple workspaces on Slack using this single account.
I want to achieve the same in my application too. I am curious that how Slack is supporting this feature right now? Does it send some ID with every request to the server which indicates that the activity which just has been done is associated with the workspace under this ID? Or there is some unique sort of token associated with every workspace (on Slack API level)?
I do have such a model in my app. A unique auth_token is associated with every company account. So, I am thinking that when an employee wants to do an activity for a specific company he will send this unique token with the request to the server so that server knows for which company the activity was performed.
Does anybody know what is the best way of achieving this?
There are two different concepts at work here:
Relation between account and company / workspace
The data structure for the Slack account is designed such that it can be linked to multiple Slack workspaces, e.g. in SQL you would have a many-2-many relation between the accounts and the workspaces table.
Staying logged in
The way Slack and others Single-Sign-On provides like Google SSO keep you logged in is by settings a browser cookie. That cookie would usually be some kind of crypto hash and the SSO provider will use it to identify to which account the current user belongs to or to request a login via OAuth if the cookie is missing / invalid.
This can also be achieved partly with server sessions (which also uses cookies). Using server sessions is easier to implement than implementing your own (secure) cookie solution, however the user will only stay logged in as long as the browser stays open. But that should be sufficient for most solutions.
Note that tokens for the Slack API work very differently. e.g. they have to be generated per workspace, user and app.
Recently google has added multiple user support to the assistant so how would use the API to identify the person by voice?
It depends what you mean by "identify the person".
There is no way for an Action to get the raw audio, so there is no way for it to do voice printing or anything along those lines.
Although each voice has to be reported against a Google User ID, you do not have direct access to that user ID.
What developers do have access to is a UID that is sent along with each request to your fulfillment server. This UID is consistent across requests, although it can be reset by a user (for example, if they reset their Google Home). You can think of this the same way you think of an HTTP cookie - you can track the UID and, if you see it again, have reasonable assurance it is the same user that accessed it last time. This breaks down, however, for the "default" account on Google Home, since anybody who doesn't have an account will map to this user.
Beyond this, you can also use Account Linking to connect a Google Account consistently to an account in your own system. If you have sufficient authentication in place, or are using one from Google or Facebook for example, this can act as an identity.
There isn't an API for developers to identify users by voice.
I am developing a web app for a group, and I want to be able to let anyone in the group create an event and add it to the group's calendar through the app. I was able to get the basic functionality working using Google Calendar API v3 for Javascript -- you could fill out a form with the event's start/end times, title, information, etc, and it could insert that event into the calendar.
But the problem is with authentication. If a user is logged in to a Google account that is not given permission to create events on the calendar, they are unable to add the event (Javascript writes "Forbidden" to the console). If I log out of all Google accounts and then sign in with the account that owns the calendar, the event is created with no problems (that makes sense).
Adding every single person in the group to the edit-permissions on the calendar seems like too much of a "brute force" method.
Is there a way to always authenticate the Google account that owns the calendar? Or, better yet, is there a way just to force authentication in general, even if someone is already logged in to Google / authorized to the app? Some people in the group know the calendar login/password, so if I could always bring up a Google login screen, they could just enter the calendar account information and then add the event from there. Again, I'm using Javascript (not much documentation on this...).
Thanks!
Have a look at Service Accounts. That way the calendar is owned by the application, and so the application will always have permission to update it.
If you want to avoid authentication problem from other opened session in user browser, you have to authenticate on the calendar, using server side library.
check this link:
https://developers.google.com/google-apps/calendar/auth
it bounces you from one article to other, but at the end you should get all information.
Google published that they are testing a feature that allows you to sign in simultaneously to multiple Google accounts in the same browser.
Any idea how would that be implemented ?
I don’t have any inside info on how multiple accounts are actually supported, but here’s what I presume:
Your cookie holds a security token, just like in the old days.
The security token now maps to a set of signed-in accounts on the server.
I’d guess there’s a notion of an active account among this set.
When you go to a Google service that implements multiple-account support, the service pulls down your active account and drops you into that account by default.
Then, you get presented with some UI that lets you toggle between your other signed-in accounts or lets you sign into a new account.