Is it possible to stop a session from inside aws-lambda code if you run lambda seperately from skill.
I am trying to run aws-lambda function from SNS to stop skill session.
From what I've ready my interpretation is that you're interested in ending the session on your Amazon echo by sending an SNS message to an unrelated lambda function. If that is correct this is how I would proceed.
I have not tried this but having extensive experience with Amazon Alexa Skills in Node.js I would say this might be accomplished in a programmatic way as follows:
1) Enable a dynamodb table within your alexa app. (as seen in line 4)
exports.handler = function(event, context, callback) {
var alexa = Alexa.handler(event, context);
alexa.appId = `YOUR_ALEXA_SKILL_ID`;
alexa.dynamoDBTableName = 'NAME_OF_YOUR_DYNAMODB_TABLE'; //You literally dont need any other code it just does the saving and loading??!! WHAT?
alexa.registerHandlers(newSessionHandlers, newGameYesNoHandlers);
alexa.execute();
};
Alexa will then create a single datatable row for each unique user. Note you'll need to set up an IAm permission to allow lambda to access this data table.
2) When your session starts have it update a value in it's own data table row so that this.attributes['EXECUTING'] = True;
3) During each consecutive intent call within the session check the value of this.attributes['EXECUTING] if the value is True, Great, if it is False end the session by emitting this.emit(':tell', "Goodbye!");
4) Now, the data table rows are indexed by userId. This will be the tricky part that I have not personally tried. I suggest creating an intent where the user ask for their userId, then emit a card with the id value on it. This could then be copied into your own SMS lambda function or some other api. Alternatively amazon has recently released documentation on how to connect alexa users to your own API's.
https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/linking-an-alexa-user-with-a-user-in-your-system
It really depends on what you're hoping the final product will look like.
5) Finally, use your external api or alternate lambda function along with the users userId to access the same dynamodb table and alter the value of ['EXECUTING'] to False. The next intent that is run will then check the database and cause the skill to exit.
Voila!
For more on specific code, account linking, and sms please ask additional questions. Thanks
Related
I am working on the requirement where the data entered in the form needs to be validated manually and once validated , a approval mail be be sent out and then data will be stored in the database.I plan to use AWS step function for this with token.
https://aws.amazon.com/blogs/compute/implementing-serverless-manual-approval-steps-in-aws-step-functions-and-amazon-api-gateway/
I plan to use a similar design like in the link above.However is there a way not to use API Gateway for sending back the task token to step function to resume processing.Did anybody worked on the similar requirement and how the functionality was achieved. Thank you.
Step function can be invoked by the AWS Lambda function as well.
Once the form is validated and stored in database, you can trigger the Lambda function based on the database events(ex- if DynamoDB used then based on the DynamDB streams), and the lambda can start the step function.
Does Amazon Cognito support temporary users? For my use case, I want to be able to give access to external users, but limited to a time period (e.g. 7 days)
Currently, my solution is something like:
Create User in User Group
Schedule cron job to run in x days
Job will disable/remove User from User Group
This all seems to be quite manual and I was hoping Cognito provides something similar automatically.
Unfortunately there is no functionality used to automate this workflow so you would need to devise your own solution.
I would suggest the below approach to handling this:
Create a Lambda function that is able to post process a user sign up. This Lambda function would create a CloudWatch Event with a schedule for 7 days in the future. Using the SDK you would create the event and assign a target of another Lambda function. When you specify the target in the put_targets function use the Input parameter to pass in your own JSON, this should contain a metadata item related to the user.
You would then create a post confirmation Lambda trigger which would trigger the Lambda you created in the above step. This would allow you to schedule an event every time a user signs up.
Finally create the target Lambda for the CloudWatch event, this will access the input passed in from the trigger and can use the AWS SDK to perform any cognito functions you might want to use such as deleting the user.
The benefit to using these services rather a cron, is that you can perform the most optimal processing only when it is required. If you have many users in this temporary group you would need to loop through every user and compare if its ready to be removed for a one time script (and perhaps sometimes never remove users).
My solution for this is the following: Instead of creating a post confirmation lambda trigger you can also create a pre authentication lambda trigger. This trigger will check for the user attribute "valid_until" which contains a unix timestamp. The pre authentication lambda trigger will only let the user in if the value of the "valid_until" attribute is in the future. Main benefit of this solution is that you don't need any cron-jobs.
I have a requirement to build a basic "3 failed login attempts and your account gets locked" functionality. The project uses AWS Cognito for Authentication, and the Cognito PreAuth and PostAuth triggers to run a Lambda function look like they will help here.
So the basic flow is to increment a counter in the PreAuth lambda, check it and block login there, or reset the counter in the PostAuth lambda (so successful logins dont end up locking the user out). Essentially it boils down to:
PreAuth Lambda
if failed-login-count > LIMIT:
block login
else:
increment failed-login-count
PostAuth Lambda
reset failed-login-count to zero
Now at the moment I am using a dedicated DynamoDB table to store the failed-login-count for a given user. This seems to work fine for now.
Then I figured it'd be neater to use a custom attribute in Cognito (using CognitoIdentityServiceProvider.adminUpdateUserAttributes) so I could throw away the DynamoDB table.
However reading https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-dg.pdf the section titled "Configuring User Pool Attributes" states:
Attributes are pieces of information that help you identify individual users, such as name, email, and phone number. Not all information about your users should be stored in attributes. For example, user data that changes frequently, such as usage statistics or game scores, should be kept in a separate data store, such as Amazon Cognito Sync or Amazon DynamoDB.
Given that the counter will change on every single login attempt, the docs would seem to indicate I shouldn't do this...
But can anyone tell me why? Or if there would be some negative consequence of doing so?
As far as I can see, Cognito billing is purely based on storage (i.e. number of users), and not operations, whereas Dynamo charges for read/write/storage.
Could it simply be AWS not wanting people to abuse Cognito as a storage mechanism? Or am I being daft?
We are dealing with similar problem and main reason why we have decided to store extra attributes in DB is that Cognito has quotas for all the actions and "AdminUpdateUserAttributes" is limited to 25 per second.
More information here:
https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html
So if you have a pool with 100k or more it can create a bottle neck if wanted to update a Cognito user records with every login etc.
Cognito UserAttributes are meant to store information about the users. This information can then be read from the client using the AWS Cognito SDK, or just by decoding the idToken on the client-side. Every custom attribute you add will be visible on the client-side.
Another downside of custom attributes is that:
You only have 25 values to set
They cannot be removed or changed once added to the user pool.
I have personally used custom attributes and the interface to manipulate them is not excellent. But that is just a personal thought.
If you want to store this information, and not depend on DynamoDB, you can use Amazon Cognito Sync. Besides the service, it offers a client with great features that you can incorporate to your app.
AWS DynamoDb appears to be your best option, it is commonly used for such use cases. Some of the benefits of using it:
You can store separate record for each login attempt with as much info as you want such as ip address, location, user-agent etc. You can also add datetime that can be used by pre-auth Lambda to query by time range for example failed attempt within last 30 minutes
You don't need to manage table because you can set TTL for DynamoDb record so that record will be deleted automatically after specified time.
You can also archive items in S3
I don't know how to subscribe to changes in DynamoDB database. Let me show an example: User A sends a message (which is saved in the database) to User B and in the User B's app the message automatically appears.
I know this is possible with recently released AWS AppSync, but I couldn't integrate it with Ionic (which I am using). However, there must be an alternative since AWS AppSync was released only at the end of 2017/beginning of 2018.
I've also seen something called Streams in DynamoDB but not sure if that's what I need.
DynamoDB Streams is designed specifically for capturing/subscribing to table activity. You can set up a Lambda Function with your notification logic to process the stream and send notifications accordingly.
I am building a chatbot for a website that has lots of traffic
I decided to build chatbot in AWS lex
I want to save all chat conversation an single attribute in Dynamo DB for that I had chosen list data type for that attribute
and I am able to get all the slot data into different variables but how to save user entered utterance and prompts that we defined in lex console and how to arrange them like a conversation.
If is there any alternative for storing chat conversation?
Since it's your bot, you know the session timeout value. In your lambda function you can generate a session id (random UUID) and put that in session attribute (read more here). You can create a DDB table in your account and design it like this:
Hash Key: userId
Range Key: sessionId#timeStamp
Request (String attribute): JSON format of request structure that is sent to Lambda function
Now as long as the session is valid you can always retrieve the sessionId that you put in session attributes map. Using this you will always be able to create the range key (sessionId + "#" + currentTimeStamp). In every call that you get in your lambda you also get the user-id for your bot. You can all this information to store the utterances the way you might like.