-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FaunaDB user storage #31
Conversation
@jchris nice, I'll check this later today |
I'm enhancing this to make it so the userStorage can return a user token that is threaded through the JWT and the API Gateway authorizer, so you can for instance have the user model return a database access token that other functions can use to connect to the database on behalf of the user. (At least that's what I'm using it for.) The main thing that can be changed here is |
I'm working on another finishing touch for the test-token handler so that it doesn't have share |
The user is saved to DB as expected, but I keep getting {
"name": "PermissionDenied",
"message": "permission denied",
"requestResult": {
"client": {
"_baseUrl": "https://cloud.faunadb.com:443",
"_timeout": 60000,
"_secret": "######",
"_observer": null
},
"method": "POST",
"path": "",
"query": null,
"requestContent": {
"get": {
"match": {
"index": "userId"
},
"terms": "######"
}
},
"responseContent": {
"errors": [
{
"position": [
"get"
],
"code": "permission denied",
"description": "Insufficient privileges to perform the action."
}
]
},
"statusCode": 403,
"responseHeaders": {
"content-type": "application/json;charset=utf-8",
"date": "Thu, 23 Feb 2017 22:12:53 GMT",
"x-faunadb-build": "2.1.26-3e4e327",
"x-faunadb-host": "ec2-52-91-30-141.compute-1.amazonaws.com",
"content-length": "123",
"connection": "Close"
},
"startTime": 1487887973143,
"endTime": 1487887973184
}
} |
I'm looking forward to playing with this repo, after I get the scope example working from youtube serverless. |
Thank you for reviewing this. There is one issue that might be causing what
you're seeing. The refresh token function does not maintain the user data.
So I plan to work on adding that bit of the flow today or tomorrow.
Is there a security reason why the cache shouldn't store this user data and
attach it to the refresh token? That is my plan. But it is not always clear
which aspects of a single sign on architecture are mitigating attack
vectors, and which are just feature driven.
|
This is still not ready to merge. I'm running into CORS stuff which I hope is just workstation related, but is making me question the sanity of my changes in If you had it (almost) working before and only deploy the testToken function, that's probably the best thing to do at the moment. I've moved it to a query that should work with the FaunaDB secret. (Before it was trying to query an index that is not available to user-level keys.) |
Now I got it working. The Here's one option how to fix it: const createResponse = (statusCode, payload) => ({
statusCode,
body: JSON.stringify(payload),
});
const contentHandler = (event, context, cb) => {
console.log('event', event);
const authData = event.requestContext.authorizer;
if (authData.principalId) {
if (authData.faunadb) {
const client = new faunadb.Client({ secret: authData.faunadb });
client.query(q.Get(q.Ref(`classes/${userClassName}/self`)))
.then((result) => {
console.log('result', result);
cb(null, createResponse(200, result));
})
.catch((error) => {
console.log('error', error);
cb(null, createResponse(400, error));
});
} else {
cb(null, createResponse(200, { username: authData.principalId }));
}
} else {
cb(null, createResponse(400, { error: 'Invalid request' }));
}
}; I'm also thinking of splitting the
Then there would be fewer if-else statements. |
About the refresh tokens, here is a blog post from Auth0 https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/. I think the refresh token should be just a random token and it is used to get new authorization token. |
Thanks for the feedback. I'm not sure if it makes sense to have a Dynamo testToken, since the token service doesn't read from storage usually. The reason I added FaunaDB to the testToken, is to show how it can look when your database is user-aware. Maybe in a case where Cognito is being used to store the content, and Cognito users are authenticating, that would make sense, but I don't know Cognito well enough to say. I think I will be able to keep the refresh token architecture the same, and just add some user data to the cache objects. |
The |
Allows user storage to attach database access token or other secrets to the Authorization Token. The authorizer converts these to API Gateway context, so they are available to authorized functions. In the case of FaunaDB we use this payload to deliver a FaunaDB access secret that corresponds to the authenticated user.
I've cleaned this up to be as great as I can make it, and rebased it to one commit to remove a lot of the back and forth I did while figuring things out. This is working great for me. Thanks for reviewing the earlier effort. This is ready to merge if it passes review. |
Works perfectly 👍 I'll review the code later today. |
Btw I'm working on a blogpost about this here.
https://github.com/serverless/blog/pull/106/files#diff-2292421f7c0ac2f9855ccd791a7eb132
😀
On Tue, Mar 7, 2017 at 2:13 PM Eetu Tuomala ***@***.***> wrote:
Merged #31
<#31>
.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#31 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAA_VZynxMSWK3gkY55oy59w9bB_fW_ks5rjdaBgaJpZM4ME6fp>
.
--
971-235-1414
http://twitter.com/jchris
|
That's nice 👍 |
This PR adds support for using FaunaDB Serverless Cloud as user storage.
thanks!
Chris