I need to send timeline item to particular subscribed user using Mirror API. I have the user's email id. How can I achive this?
Thanks
Update:
I have GDK app, companion app(which runs on Android mobile device) and Mirror API app. Both GDK app and companion paired via Bluetooth. My use case is I have to send timeline item to uesr if he reached particular location. We are using ibeacon to check user's location. When user reached that particular area, companion app detect it(via bluetooth) and send request to mirror app then mirror app will add timeline item to user's glass. Here my question is how to add the timeline item to one particular user?(not to all subscribed users) And what parameter should I pass to mirror app from companion app?(I was thinking to send the user's email id)
The user will have needed to log into your service using OAuth2 and have granted specific permission for you to access their timeline using the role https://www.googleapis.com/auth/glass.timeline. You should request "offline" access so you will receive both an auth token and a refresh token, which you can use to get a new auth token after an hour.
You will need this auth token when you send a card to the timeline, which also serves as an identifier in this case. Having their email id is not enough, and you don't need it.
See https://developers.google.com/glass/develop/mirror/authorization for some code samples and details.
Update:
So it sounds like you have the following overall work flow:
User creates an account on your website (which is where the Mirror API app is hosted). As part of this, they authorize access to their Glass and either give you their email address or authorize you to get it via Google's API.
You'll store this information (auth_token and refresh_token) in a data store somewhere, indexed against their email address.
They will also install your app on their phone, and it has access to the email address as well.
When the mobile app detects an ibeacon marker it is interested in, it connects to your web service and sends the email address and location.
Your web service looks up the email address, gets the access token to authenticate the connection to the Mirror service, and sends a message to Glass with the location information.
This is a generally reasonable workflow, but there are a couple of important points to make:
The Mirror API is well tuned to sending things to just one person at a time. You sound worried about sending bulk results, but as long as you use the auth token for just one user, it will send it to just that user.
You're using the email address as an index to the entire user account. While this is simple to implement, this is not the best solution, since it means that anyone who has a person's email address and the URL for the endpoint of your service can fake locations. You may consider this an acceptable risk given how you're using the location information (sending it back to the user), but you need to think about how the service could be misused.
You can mitigate the risk in a couple of potential ways:
Instead of an easily guessable email address, you can create and use some other userid which the user will need to enter when they first setup the companion app.
The first time (and only the first time) the app wants to connect to the service, it creates and sends a random secret string which it will use as a password and the web service could store this random string. Afterwards, the companion app would need to send this string along with the email address.
Depending on your needs, you could cut out the webapp completely and have the companion app use the Mirror API directly. This would leave the auth tokens on the phone and would greatly reduce the potential chance to have someone spoof your user. It does have a significant downside - although you can use it to send cards to Glass, it becomes more difficult to get responses from Glass back to the companion device.
As I understand your question and comments above, your user has already authenticated with your Mirror API based application, so you already have the required credentials (auth/refresh tokens). Your companion Android application detects a condition (user in a particular area) and sends a request to your remote endpoint in your Mirror API based application.
The companion app, when sending the request to the remote endpoint, needs to send a common piece of information that can be used to identify that user in your Mirror API app. In this case, you're saying you're sending the users email id.
To send a timeline card to only that particular user, I would take the email id that the companion application has sent, query your database to return the credentials that you saved when the user authenticated originally with your Mirror API based app and then use that to create an authenticated Mirror API request that inserts the timeline item for only that user. I don't know what your Mirror API app is written in, but a basic example in Python might take the following form:
# You sent along the email address
userid = notification['MyCompEmailId']
# set timeline card body
timelinecard_body = {
'notification': {'level': 'DEFAULT'},
'text': "You found a beacon!",
'menuItems': [{'action': 'DELETE'}]
}
# Look up the user in our database and
# get their credentials
#
# _credentials_for_user() basically does a "WHERE userid = 'something'" query
user_credentials = _credentials_for_user(userid).get()
# Create a Mirror API service with some credentials.
authed_mirror_service = build('mirror', 'v1', http=user_credentials.authorize(httplib2.Http()))
# Send a timeline card
authed_mirror_service.timeline().insert(body=timelinecard_body).execute()
Related
I'm currently trying to make an account signup page for a small project I'm working on and I don't know how to send data back to the server (I'm using the Flask framework) without also allowing everyone to send data. Let's say that I've set up an API endpoint on /createAccount. I can then send POST requests to that endpoint: {"username": "test", "password": "test"}. The web server will then handle that request by inserting that data into a database and responding with 201. The problem is, anybody would be able to send these requests, and I only want users to be able to register through the login page, and not by making an API call. Is there any way of doing this?
Edit: I've given this problem a bit more thought and I think that the only API that is difficult to secure is the signup API. When a user has created an account, I can just assign them an API key, which they will send to the API every time they want to make a request, which means that an account is required to make API calls. If a certain key is making too many requests, they can be rate limited or temporarily banned from making further requests. The problem with the signup API however, is that there is no information by witch a request sender could be identified. I could use the IP address, but that can be changed and wouldn't really help if multiple IPs are spamming the API at the same time. Is there a way I can identify non-registered users?
Short answer: no.
You have to check data to make sure the account being created is something legit and not trash data to fill your database or any other malicious intents.
This is the reason you usually have to confirm an account clicking on a confirmation link sent to your mail: this way the app is sure that your account is legit.
You could also check info on the front end, but that is never as secure as back end checking, because of your concern in the question: in the end, anyone who gets to know your endpoints could potentially send direct requests to your server with whatever data they wanted.
Assuming you have a trusted source of registrations, an if that source can make an ssh connection to the server where your Flask app is running, an alternative to trying to lock down a registration API is to provide a command line script to do the registration.
The trusted source does something like
ssh someuser#youripaddress /path/to/register.py "username" "password" "other info"
If you use a Flask custom command you can share model definitions db configuration.
I am using Django 2.2 for my webapp.
And I have been looking for tutorials that cater for QR code cross login to webapp using mobile app.
Basically the workflow is like this:
expected workflow
User arrives at website on desktop
Given a choice of username/password or QR code login (We assume user is registered)
User chooses QR code to login
User is prompted to install mobile app (can be android or iOS)
User installs mobile app and logins using username/password.
On mobile app, user then agrees to future login using QR code as alternative (this is done once)
After this, in future logins, when User chooses QR code to login as per step 3. They use the mobile app to scan QR code generated on the website login page.
The mobile app then uses FaceID or FingerPrint ID (assuming iOS) to then allow login. The user presses a Yes button on the mobile app to confirm login.
Somehow the webapp is notified dynamically and allows login on the desktop browser.
I don't quite get how the mobile and the web app at the backend all work with one another to achieve this seamlessly.
What I did find
I did find this library https://github.com/aruseni/django-qrauth which seems no longer maintained. But I still cannot quite get how the flow works between mobile app and webapp backend.
I also found this https://medium.com/#ksarthak4ever/django-two-factor-authentication-2ece42748610 which seems to use the mobile phone as a 2FA device. Not exactly the use case I am looking for unless I misunderstood.
I did find this article https://backendless.com/how-to-implement-mobile-to-web-cross-login-using-a-qr-code/ which is what gave me the term "cross login". However, the article is tilted heavily towards this particular vendor.
I am looking for an "understanding" of the concept without being reliant on the specifics of the vendor implementation.
What I am not looking for
In case, my question is poorly phrased and gets misunderstood, I have included this section to make clear what I am not looking for.
I am not looking for the use case where the QR code serves as a 2FA confirmation for the authenticator app.
I am also not looking at code examples yet. I just want a clear understanding first of how things work between the mobile and web app. I believe JWT is needed though I am guessing.
A workflow is more appreciated than actual code because I want to gain an understanding first of how this works.
The key concept is that login occurs when a user and browser are matched. A user means a user(or a user device) already recognized(authenticated) by the server.
user's PC browser requests QR login to server (without any account information)
server makes login request key and send the key to the user's browser. the key is displayed as QR code. (the role of this key is to identify the browser)
user's already logged-in device(user) read the key(QR) and sends a login acceptance request to the server with the key.
At this point, the server knows who both the user and the browser are.
The server allows the browser to log in as the user.
The key to identify browser could be session or web socket channel or any other form of information.
The server must store the key until the login process is complete.
If a valid login acceptance request is received, the server should prompt the browser to log in.(server->client, push). there are several techniques for accomplishing this.(polling via AJAX, Web socket, push notification services, etc..)
I'll explain it with Django-channels web socket framework. (In this case login request key and channel name is same. but different key and channel name is also okay.)
browser: user chooses QR login. (without any account information)
Backend: web socket channel is made. name of the channel is securely randomly generated string(FOO). key(FOO) is stored in redis as Django-channels[redis] made a channel named that string(FOO). send the key(FOO) to user's browser.
browser: get the key(=channel name=FOO) and open the web socket channel(FOO). and also displays QR code(FOO).
user(smart phone): user launch smart phone app(already logged in). and scan the QR code(FOO). user smart phone app send a login acceptance request to the server with QR code's information(FOO)
Backend: server send securely generated login key(BAR) via web socket channel(FOO).
browser: get login key(BAR) via web socket channel(name is FOO) and redirect to login url with login key(BAR).
server: get the login key(BAR) and let the browser to log in as the user
login request key(FOO) could be a JWT(contains key, url, expire, etc..) or just secure string(varies depending on the scenario). it doesn't contains account information and server must store it.
login key(BAR) is usually a JWT. with JWT, it contains account information and server does not have to store the key.(stateless)
I think you wanna do something like WhatsApp’s web where the users log to the web app by QR code, if I was doing such implementation I’ll do it as follows.
When the user arrives to the login page, we create a logInSession with a random token and we save it to the database.
we send that random token to the browser, which will render QR code based on the random token. We start a pooling for ‘log_me_in’ view to check if the user scanned the barcode.
The user goes to the mobile app and select log-on browser activity which will launch the camera.
Once QR is read on the phone, make a request to the backend with the scanned token and update the logInSession with the username.
With the next call to ‘log_me_in’ view, log the user in based on the username and tell js to redirect to homepage.
Hope this is clear enough.
I'm developing a custom passwordless auth to sign into a Cognito user pool. I will describe what I'm trying to implement in case anything is silly. I want a user to enter their email address, then receive a magic login link via email, and when they click on that be taken back to the site and be logged in.
This uses custom auth lambda functions to define/create a challenge with a time based password and send it to the user in an email. I am having a couple of problems:
Problem 1)
When the user returns with the code they might not be in the same browser/device and certainly won't be in the same tab so they don't have the session, meaning I need to call cognitoUser.initiateAuth again. This goes through the define/create challenge lambdas again so a second email gets sent even though at this point the user is coming from the email link so already has the code. Note: the session id is not available in the event object when the challenge is created, also I've read these sessions only last 3 minutes and my time based passwords will last ~15minutes, so I don't think I can include the session id in the email.
Problem 2)
You can login from a few places (browser, android app, etc) and I would like to be able to include the url or at least protocol as a parameter to control what gets sent in the email, e.g. if you entered your email address in the android app then the email you get would be myapp://login?code=xxx and if you did it on the web it would be https://example.com/login?code=xxx
It seems like I would be able to implement both of these to work properly if only I could find some way to send custom metadata through to the DefineChallenge and CreateChallenge lambda such that it would appear in the event object. I thought adding ValidationData to the AuthenticationDetails object would do this, but that information doesn't appear in the event object in the Lambda fns.
The workaround I've found is to create a new client id for every situation - one for initiating auth, one for redeeming token, and repeat for each different protocol. But that is a lot of client ids quickly - a pain to mantain and clumsy.
So tl;dr is: I want to send custom metadata from my cognitoUser.initiateAuth(...) call in JS and have it available in my Define/Create Challenge lambda fns.
You can split the authentication process into multiple custom auth challenges. This allows custom auth state to be supplied via the challenge response as client metadata.
Auth session state must be persisted in a database in order to be shared between devices.
Your custom login flow will probably have two challenge steps: the first prompts for auth type and the second prompts for the secret code. The action taken by the "Create Auth Challenge" Lambda will depend on the auth type. If the auth type is "Email" then the secret code and magic link are generated, stored in DynamoDB and emailed. If the auth type is "MagicLink" then the secret is loaded from DynamoDB. Clicking on a Magic link will initiate a new auth session and automatically supply all the challenge answers.
There are a few other things to consider:
Your magic link needs to encapsulate the Cognito username as well as the one-time secret and probably some other session id that is used as a key in dynamodb.
You probably should not put app-specific links into your emails. Instead associate your domain with your app and/or leverage the redirect URI parameter of your web-based login page.
You can also access custom Cognito user attributes from the Lambda function which can be used to indicate user login preferences (eg Email vs SMS for login codes).
Is it possible to use userID and the API to record a user having done an event (i.e. reached a goal) by API?
For example, if I set up my GA installation to record userID for logged in users, but the Goal I want to record is something that happens when the user is offline.
Can I use an API somehow to tell Google "User 001 completed Goal X"?
Or, alternatively, can I pull a unique identifier from a user's cookie, store it on my server side linked to the user id, and fake a js call back to Google once the goal is reached, as if the user were viewing a success page?
You can fetch the client id from the cookie. Google recommends to use their get function:
ga(function(tracker) {
var clientId = tracker.get('clientId');
});
as
developers should not directly access the cookie analytics.js sets as
the cookie format might change without warning.
You can then send an event or virtual url using the measurement protocol and set up a goal based on that url or event (btw. there is nothing "fake" about it, this is exactly the thing the measurement protocol is supposed to cover).
The caveat is that the data will probably end up in a new session, so the original source might get lost (that's an issue if you do advertising).
Another approach, if your users are usually logged in, would be the User-ID feature (despite it's name it does not ID individual users, but it allows to collect user data across devices as long as an unique ID is sent per user from each device. The Id is not exposed in the interface).
You would again use the measurement protocol but this time send along the user id (you still need to send a client id, but it will be overwritten by the user id). If you enable session unification the logged-in visits of the users (and your measurement protocol calls) will be stitched together into a user-level reporting (this required a special data view which will include only data from visits that have a User Id set). Unlike the client id, which is generated by the Google Analytics Javascript code, the User ID is generated on your server and passed in to GA.
I'm trying to implement OAuth 2.0 for my API. I'm using a third party library to act as the basic OAuth provider, django-oauth2-provider,
and Tastypie as the framework. Those details shouldn't matter too much. The OAuth 2.0 works -- when a user is created, an OAuth 2 client
that manages the user's secret_key and their id is created. A customer can then supply the user ID they get back from the user creation
endpoint along with their username and password to get an access token which allows them to use API endpoints.·
Where I run into issues is retrieving the client id (which must be passed into requests for the access token). Obviously when a user is first created
I can return the client_id with the HTTP response. After that, however, there will obviously be cases where the user doesn't have their client id·
stored locally (this is a traditional user/app setup, not something like Google APIs where your client id is always visible). I want to protect
GET requests to the customer resource with OAuth, but that means I can't query the API for a given user's client ID. And it seems like the whole point
of OAuth is defeated if I can always just pass in a username and password to retrieve my client id from some oauth endpoint. Am I thinking about this wrong?
Also, from reading the OAuth specs I'm under the impression that a client id and client secret are all that should be supplied for getting granted an access token. Yet the implementation I'm using defaults to forcing the user to supply a client id, client secret, username, and password. I've overridden the implementation to require only the client id and secret, but I want to make sure that was the right call and I'm not missing something.
Edit for flup's response:
I'm dealing with a Django API as the resource server, and a user of an iPhone app as the resource owner. The iPhone app is directly associated with the server -- in other words, there are no third parties involved here and no plans to involve them in the future; all software is ours. I would think that the password flow would be what I would need in that case. Indeed, that seems to be what django-oauth2-provider supplies by default. I'd like to stay somewhat in line with what they are doing to not have to completely reinvent the wheel.
The goal of oauth2 is to let the resource owner give a client a valet key which authorizes it to access certain resources on your server on his behalf.
If there are no third parties involved, there is no client to authorize and no need to use oauth2.
Instead, you could use the standard authentication mechanisms present in tastypie.