I am using mongo db to store user data, their passwords. I have two ways of creating an account:
Regular sign up when user selects username and password and
Sign up using facebook log in.
Now, when I have regular sign up, password and username should be required, but using facebook log in they are not, so I am wondering how I should now design a schema for the users model to include both cases?
The most obvious way seems like to have two different models: users_facebook and users_regular, but is it the right way to go? Why or why not? It could also be users_auth (auth data only for users who signed up manually) and users_data (both users' types data). There is also something like MongoDB Facebook Stitch that is somehow used for the purpose it seems, although I do not get what it is. I am very new to databases and not sure which is the right way to go. The problem seems though pretty trivial.
Related
I found a previous question very similar to mine, however the other developper needed to write to Firebase and I don’t, hence this near duplicate question:
I have a very simple database with about 150 documents and the users don’t need to authenticate to use my app. Authentication just don’t make sense for what the app does and users only read the database, they don’t write.
My current rules are read allow only which of course triggers the Firebase rule warning daily.
1) Is there a way to set rules similar to “only requests coming from my app can access it”. Given that the app is linked to firebase one would think it’s possible?
2) If I must use authentification, is there a way that I can do this behind the scenes so that the user is unaware of that? Maybe by using a UUID to identify a user and no password or something like that. I want to avoid showing a log in screen at all cost. Think of it as asking to log in to check gas prices...
** This is an iOS app
No, it's not possible.
You can use anonymous authentication to create a user account without requiring a sign-in.
I want to create an app with IONIC to manage buildings. A user can hold multiple buildings. Each building has rooms. Each rooms has logs. Each user is a member of a cooperation.
For many years I've used LAMP. Now moving to mobile and made some IONIC apps. With 2 apps I've used sqlLite as datastore on the mobile device.
But now I've read up on couchDB and pouchDB and really like the concept and the sync option. So now I'm looking into this to use as my datastore (on the mobile and also on the backend).
Now I've got 2 major questions/concerns:
1) Authentication
In my LAMP situation, I usually have an SESSION (table which holds the sessions strings and userID) and an USERS table.
When the user logs in, the user is lookup in the USERS table, and a session string is created and saved with the userID.
Now each time a request is made to the server (for example update data), the session string is also supplied and matched to the SESSION table and retrieve the correct user. From that point on, I can validate if the post is valid and the data also belongs to the correct user.
Back to couchDB, I know there is a cookie management in couchDB (http://guide.couchdb.org/editions/1/en/security.html).
So here I can validate if an user exists and validate the credentials. Now the app can send requests with a cookie.
2) Fetch/Update the right data
In my LAMP situation, I always knew which data belongs to which user. And the back end always checks if this is correct.
In my couchDB I want to create database and each document is an user with all the data.
So now here comes the problem. I can validate an user in couchDB, put there's no way to validate the data (at least as far I know of) that it belongs to the right user.
My goal is that the mobile device syncs the document to the couchDB server.
3) Database structure
At first I wanted to create a database per user. But this is not scalable. Also an user is an member of a cooperation. I also need to generate reports per cooperation/user.
So now I was thinking to create a database per cooperation. But now the problem is, when a user login, I need to know wich database to connect to lookup the user data.
Now I want to use 1 database and each document is an user and holds al data (buildings/logs).
Has anybody got some other suggestions/resources on this approach?
You can try couchdb in combination with superlogin:
SuperLogin is a full-featured NodeJS/Express user authentication solution for APIs and Single Page Apps (SPA) using CouchDB or Cloudant.
github
Tutorial
I don't see an easy way to grant permissions to another user. It seems to be quite convoluted at the moment, and I wonder if I'm missing something obvious.
Say I want to invite another user to share a Realm. First I would have to ask the other user for their identification, then I would create the permission object, and then finally I would give the other user the address of my realm.
It would be great if I could share some sort of permission token via text message and let the new user register themselves. I suppose I could do that if I created another "User" which represented the shared group, and merely share this abstract user's credentials. It feels a bit hacky that way, but it seems easier to do.
I was hoping the demo application of the shared drawing environment would hold a clue, but after looking at the source code, it turns out both devices are logged in as the same user.
Am I missing something? Given the demo Draw application, how would one user practically invite a second user to join in their shared drawing environment? It seems like there would have to be a whole set of convoluted permissions and url/identification sharing handshakes.
Thanks for asking the question! Today, you will need to create a shared Realm that all users would input their user IDs into and have access to. This way any user can look up an ID and share access to another Realm.
We realize the limitations and are working on offering a number of improvements. The first is pretty close to what you describe, called a PermissionOffer object where you can inform the Realm Object Server you want to grant access to another user for a given Realm(s). The server will then provide a token you can share via any means with the other user. That user can then use the token to create a PermissionOfferResponse object and accept the access grant. This is coming soon, so stay tuned!
Later, we plan to offer a way to lookup user IDs so you don't have to replicate all of them in a shared Realm (see this issue).
I am building a web-app with Meteor and i am using the Meteor Accounts-password package and accounts-facebook package to make login easy. The user has some information tied to them like email & password, but i want to tie more information to them after the account has been created.
I know of two ways that i could do that and i was wondering how i should do it, since i can't seem to find any information about it on the internet.
Option 1:
I add all the additional information (like username, displayname and other stuff) inside the Meteor.user.profile object. This seems to be a bad solution since users by default have access to everything in the profile object and i have to manually deny them access.
Option 2:
I create a new collection, Profile-information, and store all additional data about the user and then tie it to the meteor.user object via some shared key. This also seems like a bad solution since i have to split my data like in SQL and not have all the advantages of embedded documents in mongodb.
This has been my thought process so far and i am at a loss of how to continue.
Which option seems to be the best way, or is there an option 3 that would work better?
Thanks in advance.
Thanks to #forallepsilon i found out that you could write any data to the user object you want. I previously though that the user object was locked, and you could only store additional data in the profile field.
I will store the additional data i have about the user inside the Meteor.user object by just creating additional fields.
I am implementing an mobile app for android and iOS and I am using GAE with the datastore for persistance as the server side of my app. My app uses facebook login for user authentication. One of the key aspects of the app is that users can interact with each other through the app but I want to keep their actual facebook-id secret so that user cannot discover the facebook profile of another user through my app.
My original design for this was using MySQL and there I had a simple implementation of a users table with the table primary key, an auto-increment integer served as the user id for the app. So I could safely send the user id of other users to the client app, and this did not give away any information I did not want to give away. When a user logs in, the client app performs all the necessary facebook login procedures and sends the facebook access token to the server. The server would extract the facebook user information from this token chech if a user with this id already exists, if so use this user row, otherwise create a new one.
On an SQL database this works great since it is strongly consistent, and there is no way I will "miss" the fact that the user is already in the table. However now when I am using the eventual consistent datastore with the same idea, I ran into a problem where if a user logs in for the first time ever, an entry is added to the datastore, but then if the user logs in again shortly after the query I am performing to check if a "User" entity with the same facebook-id is already present this query sometimes still return no results. This leads to the same facebook id being assosiated with 2 different users of my app and this is obviously bad.
(I know this seems like an unlikely scenario, but I actually accidentally ran into it during development)
I thought of a few ways to mitigate this:
Instead of using the app user id as the entity key use the facebook id, this ensures consistency (since there is no index involved in the lookup now). This would imply I need to use the facebook id as the id for my app and this violates one of the design principles (the facebook id of other users will now leak to the client app).
Instead of relying on the datastore generated entity key id for the user, specify the id myself, by performing some sort of deterministic manipulation of the facebook user id, such as a hashing it or encrypting it. This way I can use the key to perform the lookup and no matter how many times the same user logs in their user id will be generated the same. But this seems like too heavy an approach to do correctly. If I hash it I will need to make sure to use a good hashing algorithm to prevent collisions. A good hash or encryption will output a long string as a user id, which is not too bad, but I would like to keep the user id as a simple long integer value if possible.
Accept the fact that this is eventually consistent, during a log in if we find more then one corresponding entity, delete them and stay with one. This is bad, because what if the user has already performed some operations that are stored on the previous entity? I will have to run through all the data for the multiple user entities from the same user and perform some sort of merging operation on them. This will also require me to run through other entities that store the user id and change them all.
Use memcache to store the user, this will probably make this scenario even more unlikely, but not eliminate it entirely. Memcache entries can be evicted prematurely, and in this case we are back to swaure one.
What is the best approach here? Is there something I am missing? Would really appropriate your input.