I'm working on my online shop pet project. For authorised user I store data in postgres db (user cart, favourite products etc). For unauthorised user I store data in localStorage, is it a right decision or should I use something like Redis for such data?
Related
I am using Azure B2C to take care of user management in my ASP.NET Core application following this example.
My application needs to store custom data for each user. This is something I haven't seen done in any Azure AD examples.
The stored data is too complex to be stored in AD user attributes.
What is the best practice for implementing this user ownership scheme when using Azure AD?
Would adding userID property on all my models make sense? This ID would then be the ID of the owning user in AD. Is there a better way?
I present two possible approaches possible but I recommend the first one:
Store user's data in the external data store and correlate this data with the user using objectID (user ID) from the Azure AD B2C. In this case, once the user is authenticated, in the ID Token returned to your application you will find the ID of the user. Then you can query data using this ID value. This approach is recommended when you have complex model and large amount of data related to user is stored.
Get user's attributes from the external data store during user authentication (calling web API, and using objectID (user ID) from the Azure AD B2C) and embed them in the ID Token that is returned to your application. Please note that this approach is sufficient when you do not have large portion of user's data, that has to be embed in the token. You should not use it when you know that there will be huge amount of data returned because you will end up with large tokens or reach size limitations of HTTP headers. The one more downside of this approach is the fact that user's data is retrieved only during user authentication so if some property will be updated in the data store, you will have stale data in the ID Token.
Here I created the video how to retrieve the data during authentication but the concept is the same - you store user data in the external data store and refer to it using objectID (user ID from the Azure AD B2C):
https://youtu.be/_umcCiSOFv0
I am currently building a Flutter app which lets users do personality tests, and until now I planned to do it without forcing users to register an account via Firebase (as this is annoying for many users).
Problem I am facing now is that I need the results from the tests from the users, so that I can tell the users in the result section how these results are compared to the average of all people who have done the test.
If a user would now register, the test results would be saved locally on the device. Will it then still be possible to save the test results in a online database?
If you don't want to force users to sign in but still need to differentiate between them, you can use Firebase Anonymous Authentication which will create a user account in Firebase and return a UID similar to any other auth method. A new anonymous authentication can be created by using signInAnonymously() method:
UserCredential userCredential = await FirebaseAuth.instance.signInAnonymously();
As you get a unique UID for each user, you can then store data in database itself instead of storing locally. If the user proceeds with registration, you can convert this anonymous account to a permanent account using linkWithCredential method. The UID of user remains the same.
Do note that if the user logs out of the anonymous account, then there is no way to retrieve that same anonymous account back.
right now I'm working on a project where I need to dive deeper into Firebase security rules but I am not the biggest expert in this topic and I also haven't found a solution for what I need to have online.
I have a user system in the Realtime Database which has the following structure:
users -> username -> myProfile / friends / and more...
In Cloud Firestore I have stored the username so that if someone logs in he can get his username out of the document in Cloud Firestore and read the document with the title of his username in the Realtime Database (I hope that makes sense).
Now I want to write security rules which allow the user to only read his own document (which does not have the title of his uid but of his username)...
Also, I want to allow other users to read the data in users -> username -> myProfile, but only if the username of the requesting user is contained in users -> username -> friends of the person, who is requested.
To clarify an example:
Person A logs into his account, he gets his username from Cloud Firestore and wants to access his document in the Realtime Database named by his username.
Then he wants to read the data of Person B in the RD, but he should only be allowed to do this if his username is saved into the array in the friends array in the profile of Person B.
Everybody must be able to read the friends array from everyone, but only able to read the myProfile data, if his username is contained in the friend array of the other person.
Database structure
I would be super thankful for any help! If something is unclear just ask!
Micha
I am creating an application and I am looking for a solution for user authentication (checking if the user is logged in, basically). I am reading online and it seems that many people recommend using a session store/table in your db (store roles, views etc..) vs. just storing the cookie id in the DB in that users column. My question is, what is the difference between storing this data in a "session" store, which is basically just another table and storing this data in your database alongside the other user data (username, passwordHash etc..). I understand that this is useful for data that may change when the user logs in and out again, but are there any advantages to having a session store if my applications state stays consistent across log ins. Thanks.
You need a way to store user data between HTTP requests and sessions helps you to do so.When a user visits our site, it creates a new session for the user and assigns them a cookie. Next time the user comes to the site , the cookie is checked and the session id which is stored in the cookie is retrieved and searched in the session store .Session store is a place where you store all your data regarding your session.So using a session store automates this method and it eases your work.So whenever someone pings your server it will add the session id of the user in your database. I will recommend foe you to look into JWT which is also a interesting way to do authentication.
I have an interesting use case for you today.
My team and I are building a free, third party, calculator tool that enables users to calculate metrics using their store's data.
We are looking for ways to pull in the necessary data and perform the calculation to show users... so far the best we've come up with is asking the users to export a report from Shopify and upload it into our application.
Looking for a user experience similar to this:
User opens our tool, application is hosted on custom-domain.com
Somehow the user authenticates or logins in to Shopify, or approves our app temporary access to their data.
Our app performs the calculation for the user, ending data access
Any ideas as to how this authentication or access of data can be facilitated? Shopify doesn't seem to have a 'login with Google' kind of authentication button.
Thanks!
There are two modes for authenticated access, namely Online and Offline. What you need in this scenario is Online Access.
From Shopify Docs
Tokens with online access mode are linked to an individual user on a
store, where the access token's lifespan matches the lifespan of the
user's web session. This type of access mode is meant to be used when
a user is interacting with your app through the web, or when an app
must respect an individual user's permission level.This access mode
must be explicitly requested in the authorization phase.
It should also fulfill your needs related to ending data access.
An access token created with this access mode is temporary, and is guaranteed to expire after some amount of time.
When a user logs out of Shopify admin, all online mode access tokens created during the same web session are revoked.
Once you have the access token, you can use Shopify API to query data so that your users don't have to upload any files manually.