In this question Worklight: Push notification without User ID, the given answer was to subscribe a persistent cookie userID with the event source.. my question is: How can I do this? how can I use the userID given by the cookie ( I already got the userID ) to subscribe to my eventSource? Can't seem to find this anywhere on the internet
There is are additional questions you need to ask yourself, before looking into what you wrote.
Are you using Worklight 6.2 or above?
Are you looking to send generic information (i.e. not sensitive, per-user data (like bank account balance and the like))?
If the answer is 'yes' for both of the above, do not bother yourself with event source-based notifications. Instead, use either broadcast or tag-based notifications (tags = "topics of interest"). Using this approach does not require any additional work on your part other than actually sending the notification.
You can take a look at the documentation:
Developer Center: https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-6-3/notifications/push-notifications-hybrid-applications/
Knowledge Center: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_6.3.0/com.ibm.worklight.dev.doc/devref/t_tag-based_notifications_setting_up.html
In the following answer you can find an example for broadcast notifications (broadcast notification is a form of tag-based notifications): https://stackoverflow.com/a/27881423/1530814
Related
Need some help with Lambda invocation and authentication. I have an AWS Lambda function that is invoked from AWS IoT MQTT feed based on a specific topic. The invocation happens when an authenticated IoT Thing publishes to MQTT on that topic. My question is how do I see who has invoked it? I need this information so I know under what user to store the published information to database. I'm guessing there should be some environment variables that carry this information but I haven't found it. Maybe I been looking in all the wrong places:/
Many thanks,
Marcus
You should be able to modify the Lambda trigger in your IoT configuration to include the client ID by using something like the following SQL statement:
select clientId() as clientId, *
How are you?
You could send the user on the topic message. Is it not easier? Not sure how to get it from env var.
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
Suppose I have a task of updating an user via a third party API call. Is it okay to put the actual user data inside the message (if it fits)? Or should I only provide an ID in the message so the worker can retrieve the updated record from my local database?
You need to check what level of compliance is required for your infrastructure, to see what kind of data you want to put in the queue.
If there aren't any compliance restrictions, you are free to put any kind of data in your own infrastructure on AWS.
Simple question, but I suspect it doesn't have a simple or easy answer. Still, worth asking.
We're creating an implementation for push notifications using AWS with our Web Server running on EC2, sending messages to a queue on SQS, which is dealt with using Lambda, which is sent finally to SNS to be delivered to the iOS/Android apps.
The question I have is this: is there a way to query SNS endpoints based on the custom user data that you can provide on creation? The only way I see to do this so far is to list all the endpoints in a given platform application, and then search through that list for the user data I'm looking for... however, a more direct approach would be far better.
Why I want to do this is simple: if I could attach a User Identifier to these Device Endpoints, and query based on that, I could avoid completely having to save the ARN to our DynamoDB database. It would save a lot of implementation time and complexity.
Let me know what you guys think, even if what you think is that this idea is impractical and stupid, or if searching through all of them is the best way to go about this!
Cheers!
There isn't the ability to have a "where" clause in ListTopics. I see two possibilities:
Create a new SNS topic per user that has some identifiable id in it. So, for example, the ARN would be something like "arn:aws:sns:us-east-1:123456789:know-prefix-user-id". The obvious downside is that you have the potential for a boat load of SNS topics.
Use a service designed for this type of usage like PubNub. Disclaimer - I don't work for PubNub or own stock but have successfully used it in multiple projects. You'll be able to target one or many users this way.
According the the [AWS documentation][1] if you try and create a new Platform Endpoint with the same User Data you should get a response with an exception including the ARN associated with the existing PlatformEndpoint.
It's definitely not ideal, but it would be a round about way of querying the User Data Endpoint attributes via exception.
//Query CustomUserData by exception
CreatePlatformEndpointRequest cpeReq = new CreatePlatformEndpointRequest().withPlatformApplicationArn(applicationArn).withToken("dummyToken").withCustomUserData("username");
CreatePlatformEndpointResult cpeRes = client.createPlatformEndpoint(cpeReq);
You should get an exception with the ARN if an endpoint with the same withCustomUserData exists.
Then you just use that ARN and away you go.
I am doing an integration project for a customer running Microsoft Exchange 2007 (BPOS). I am looking for a way to search for e-mail using the Exchange Web Services Operations -- MS' API to their own hosted exchange solution. So far, I have found a nice API description, but as far as I can see none of it allows for searching for e-mails using different criteria. In this case, I need to find all e-mails that contains a specific sender or recipient identified by an e-mail address.
Could you provide me with guidance on how to do this? Thanks.
In my (admittedly minimal) experience with Exchange Web Services, the only way to do this would be to retrieve all items in a folder and scan through their properties.
You need to specify which properties are retrieved when you call the FindItem() operation.
PathToUnindexedFieldType fieldTypePath = new PathToUnindexedFieldType();
fieldTypePath.FieldURI = UnindexedFieldURIType.folderDisplayName;
GetFolderType folderType = new GetFolderType();
folderType.FolderShape = new FolderResponseShapeType();
folderType.FolderShape.BaseShape = DefaultShapeNamesType.IdOnly;
folderType.FolderShape.AdditionalProperties = new BasePathToElementType[1];
folderType.FolderShape.AdditionalProperties[0] = fieldTypePath;
So the only saving grace is that you don't need to retrieve the full email body etc - just the fields you explicitly require.