I have a webapp deployed on GAE and users can sign-in using OpenID. Once users are signed-in they can access the data store for their own data.
Now, if I want to establish a "shared data space", how can I achieve such a thing? Can I give access to user A to data from user B? We share entities? How can I overcome access restrictions?
Any help on this aspect will be greatly appreciated.
EDIT 1
Not quite the BigTable expert. I'm not looking for magical kingdom solution, just pointer on how to tackle this problem (blog, article, tutorial, etc).
But if I get it right, data is accessible by anyone with access to the application (if access control is available). So if I give the a {KEY, entity} pair to user B from user A he will be able to access it no problem?
Maybe I'm just confusing concepts...
The GAE datastore is a database. Data stored in it is in no way restricted to a single user. BTW, you don't even have to sign in to use a GAE application. Just query for the data you want, and you'll get it, whether the current user stored it or anyone else is irrelevant.
Related
This is my first question, so I hope I don't miss a thing. To be clear from the start: I don't expect an answer which dives deep into detail. This is just about getting a general understanding of how to work with this kind of software.
So I don't know if "Identity Management System" is a suitable term for what I mean but when I talk about Identity Management Systems I think of something like Azure AD, which as far as I know provides e.g. web developers the possibility to integrate a way users can authenticate (including access privilege etc.) on their website.
What I'm quite unsure about is how to work with/ integrate such tools in a project. I will try to make it clear with an example: Assuming I have a website let's say this website is a blog. The blog consist of different posts which are stored in my own database which is connected to the website. The posts are written by different users which authenticate with a tool like Azure AD. The user's data is stored somewhere on a server run by e.g. Microsoft. If I want to display the posts togethere with the name, email.... of the user who wrote them, how would I do this?
Is it possible to query the user's data directly from the Identity Management System and display it? This does not sound ideal to me as the consequence would be that data the website uses is stored in two different locations.
Would you kind of copy the user's data from the Identity Management System to the websites database and query it from there? This does not sound like a good solution either because then data would be duplicated.
So whats the "right workflow"?
I appreciate any hints and further information I can get:-)
AFAIK To get the user's information like name, email etc. you can add these claims while generating the JWT token.
To generate access token, you have multiple authentication flows such as Authorization code flow, ROPC flow, Implicit flow.
To add the claims that you need to return with the token, you can make settings like below:
Go to Azure Portal -> Azure Active Directory -> App Registrations -> Your app -> Token configuration -> Add optional claims
When you decode the token via JSON Web Tokens - jwt.io you can find the user information that you need.
To know how to generate access token, you can refer SO Thread which I solved it before.
We now have one site running but we will need to build a branded site for our client soon. The client site will have exactly the same data set as our current site expect for the user data. The client site must have totally separated user info which allows only the client to use the site.
I don't see the need for setting up a new database or creating a new user table for the client. My tentative solution is add a "Company" column for the user table so that I can differ which site the user data row is on.
I do not know if this approach will work or not or if it is the best practice. Could anyone with experience like this shed some light on this question?
Thanks,
Nigong
P.S. I use LAMP with AWS.
Using an extra column to store a company / entity id is a common approach for multitenant system. In general you will want to abstract the part that that verifies you can only retrieve data you're allowed to a piece that all queries go through, like your ORM. This will prevent people new to the project from exposing/using data that shouldn't be exposed/used.
2 quick question:
is it possible to build a Facebook application saving user profile informations (name, surname, phone numners, ecc.) on a external custom database (so, not FB database), obvioulsy after user approval, etc.
even if the answer of the above question is "no", do you know a way to pull out user profile information for all users who use the FB application and formally agree to give their personal information within the app? I would like to know if it is possible to do that both from a technical pov and legal pov
That´s what a privacy policy is for. In general, you should only store data after telling the user exactly what you store, what you do with the data, how long you store it and how he can get his entries deleted from your database.
Btw, you can´t get the phone number. About the technical way, please go to the Facebook docs: https://developers.facebook.com/docs
What's the best practice or the common way of keeping (or not keeping) Evernote users in your application's database?
Should I create my own membership system and create a connection to Evernote accounts?
Should I store Evernote user data (or only part of it) in my own app and let the user log in only with Evernote?
Summary: you must protect their data but how you protect it is up to you. Use the integer edam_userId to identify data.
I think the API License agreement covers protection in the terms:
you agree that when using the API you will not, directly or indirectly, take or enable another to take any of the following actions:...
1.8.4 circumvent or modify any Keys or other security mechanism employed by Evernote or the API;
If you cache people's data and your server-based app lacks security to prevent people looking at other's data, then I think you're pretty clearly violating that clause. I think it's quite elegantly written!
Couple that with the responsibility clause 1.2
You are fully responsible for all activities that occur using your Keys, regardless of whether such activities are undertaken by you or a third party.
So if you don't protect someone's cached data and another user is able to get at it, you're explicitly liable.
Having cleared up the question of your obligations to (as you'd expect) protect people's data, the question is how do you store it?
Clause 4.3 covers identifiers pretty directly although it's a bit out of date now that we are all forced to use oAuth - there are no passwords ever entered into anything other a web view. However, mobile or desktop client apps must provide a mechanism for the user to log out, which must completely remove the username and password from your application and its persistent storage.
For a web app, you can't even save the username: If your Application runs as an Internet service on a multi-user server, you must not ask for, view, store or cache the sign-in name or password of Evernote user accounts.
The good news is that you can rely on the edam_userId value which comes back to you in the oAuth token credentials response, as discussed here.
When you look at the Data Model, you can see the unique id under the User and going into the User struct, see the reassuring definition The unique numeric identifier for the account, which will not change for the lifetime of the account.
Thinking about the consequences, as you can't get the user id until you have logged into the service, if you want to provide a local login for people you will have to link your local credentials to the user id. That may irk some people if they have to enter a username twice but can't be helped.
You can allow users to log-in via OAuth. Here's a guide on how that process works.
But you'll probably also want to store a minimal amount of user data, at least a unique identifier, in your database so you can do things like create relationships between the user and their notebooks and tags. Refer to the Evernote data model for those relationships. If you're using rails, this will also help you take advantage of rails conventions.
I'm looking at ways to secure the admin section of my (cakephp powered) Facebook application. To avoid duplicating functionality, I thought it'd be neat to allow access to people who have been flagged as developers in the app settings.
The question could then be: How do I determine whether a user of my Facebook application is a developer?
Alternatively: How do I obtain an array of developer user IDs for my Facebook app?
I tried looking for your answer myself, and the only thing I found that you could possibly do is to make a group private and invite-only to developers and then use the fb:if-is-group-member tag. http://wiki.developers.facebook.com/index.php/Fb:if-is-group-member
OK, so I found out how to do it by myself. Props to Samuel for giving me the idea.
Basically, the way to do it is to run an FQL query that establishes whether a user is an admin of the applications page (page_admin).
SELECT uid FROM page_admin WHERE uid = 286302657 AND page_id = 31290624157
In the PHP client, this returns an array for developers and an empty string for anyone else.
I decided to use the FQL rather than the API call because it is possible to preload the FQL to reduce calls to the Facebook servers.
Hope this is useful to somebody.