I am building an application that can be used with or without a User being logged-in. There can only be one User logged-in at the same time. If no User is logged-in the App provides basic functionality and if a User is logged in the App provides enhanced functions, depending on the status of the User.
The properties of the User are contained in a (model) class (e.g. name, avatar, status, etc.) and I am using Provider to propagate User properties throughout the application (e.g. show name, avatar, etc.).
My question is:
Should I use a singleton for the User class?
Thanks for your time/answer,
Pierre
You should use a singleton design pattern for the user class because of the following reasons:
A singleton pattern is used when we want to have only one instance of a class in the entire app. So if you create a user class a singleton then you can access all the user detail in the entire app with only a single instance.
It will allow you to save some memory of your app. Also, it will ensure that you have only one instance of the class in the entire app.
If you want to know more about singleton pattern you can read it from here: Link
Related
I am really uncertain of how to handle the data "duplication" of the signed in user from FirebaseAuth and the project own User model fed by the users collection I create from FirebaseAuth sign ups.
For example, creating a UserAvatar widget that shows the signed in user display name and photo URL. Should I user the FireAuth User or my own users collection?
What would be the pros and the cons?
There are several considerations to take into account when deciding whether to use the FirebaseAuth user object or a separate user object from your own database.
One consideration is the purpose of the user object. If you are using the user object for authentication purposes, such as checking whether a user is logged in or verifying their credentials, then it may be more appropriate to use the FirebaseAuth user object. This is because the FirebaseAuth user object is specifically designed for these types of tasks, and it is directly tied to the user's authentication state in your Firebase project.
On the other hand, if you are using the user object to store additional information about the user that is not related to authentication, such as the user's display name or profile photo, then it may be more appropriate to use your own user object from the database. This is because the FirebaseAuth user object is limited in the amount of information it can store, and it is not intended to be used as a general-purpose user object.
There are pros and cons to both approaches. Using the FirebaseAuth user object has the advantage of being directly tied to the user's authentication state, which can be convenient for certain types of tasks. However, it is limited in the amount of information it can store, and it may not be the most flexible solution if you need to store a large amount of information about your users.
On the other hand, using your own user object from the database allows you to store more information about your users, and it gives you more flexibility in terms of the data model. However, it requires additional work to keep the user object in sync with the FirebaseAuth user object, and it may introduce additional complexity to your codebase.
Ultimately, the best approach will depend on your specific needs and the requirements of your project. You may find that a combination of both approaches works best for your use case, or that one approach is more suitable than the other.
I've been trying to create a new user in firebase with a custom UID in flutter, but it seems it only can be done using FireBaseAdmin package, and it hasn't been implemented yet in flutter. Is there's any possible way to create a new user with custom UID?
I have no background on native development, so it's not possible for me to implement the admin methods in native java or kotlin in the current time. any one has an idea on how to implement it?
The UID for a user is determine by the authentication provider that creates the user. There is no way to specify your own UID when calling to the existing providers in the client-side Firebase SDKs (such as the FlutterFire libraries).
If specifying your own UID for a user is a hard requirement, you can implement a custom provider. This does involve writing code to create a custom ID token that runs in a trusted environment (such as your development machine, a server that you control, or Cloud Functions) however.
Alternatively, you can also consider storing a mapping from Firebase-provided UID to the ID that you want to use to refer to that same user. This is a scenario regularly used to give users a unique name, so I recommend checking out questions related to unique user names.
You can use FirebaseAuthentication.
When a user create an account it will create a new user with a random UID and the UID will be unique. I assume that you can also specify you own UIDs
Here is the link : https://firebase.flutter.dev/docs/auth/usage/
Its very easy to use :p
I currently work on a iOS app witch uses Parse.com as backend. I do have the model but I'm a bit concerned about the privacy of "my" users. Since I need the functionality for a user to search for other users to send them invitations, I need the user class to be public but I don't want the email address to be public.
From what I've learned from stackoverflow is that this is a request for years.
My first idea was to add another class with all the private data and just Point to this class. The private class would be ACL secured on object level but I would lose the functionality to reset the users password.
Has anyone found a solution to keep the reset function? Is this something for cloud code?
The User data is not public on Parse. You can't directly do queries for other users.
When you do need to query for user, you explicitly add useMasterKey to your query.
I'm in the process of designing my data model for an iOS application where I'm using Parse for the backend (first time using Parse)
Every user of my application has both private data that should be readable and writable only by the owner of the data and public data which should be readable by everyone.
I'm considering keeping my publicly readable data stored in Parse's built in User object and the private data in another custom object. Is there any downside to this? My app uses Facebook Login exclusively and, thus, when a user is created the authData field is populated with "Facebook: 12345..." Is having this accessible to everyone a security problem?
In this scenario the User object (my public data) would need "Get" not "find" permissions, I just need it to be readable by anyone who knows the objectId. So that rules out anyone just dumping my entire User's table.
I've read through the documentation and the "sensitivity" of each user's authData wasn't clear. I realize that if I were using a traditional username/password scheme it would be a problem, but is it for Facebook login? Any help/tips are appreciated.
EDIT:
I printed an entire user object to the console on a test client (with another, different user logged in) and authData wasn't returned. Am I right to assume that my suggested strategy wouldn't be a problem then? authData appears to be a "special" field that isn't returned if another user fetches it.
I'm working on a small marketing project with Zend Framework, the backoffice of the project is currently made of two controller: a campaign controller and a minisite controller.
The user create a campaign with a form, then he have to create a minisite with a second form linked to this campaign, so i need to get the campaign and the user id when saving the data of the minisite.
What is the best practice and why? should i pass those variables in a session object? or should i pass those variables through a route like :
/backoffice/minisite/create/:userid/:campaign/
Edit: users are logged and authenticated when creating campaigns
Assuming users have to be logged in to do this, you could store the user information you need in a Zend_Auth identity
If not, you could store the data in a normal session var with Zend_Session or redirect to with the route. Either option is good, so it's up to you to pick the one which best suits you and your application.
For passinf information between two controller the best way is to use session to store the values globally . :-)
I'm pretty sure users need to have an account to do these things. If yes, there campaigns and minisites will be associated with them in some way. I'd store and retrieve these things from some form of database.
If you're not having authenticated users and you really just need to pass two variables to another action, use url parameters but be aware of the fact that users can mess with them and a lot of unexpected stuff can happen. Storing in the session is harder to manipulate in that way.
So, if no authentication is involved and the site is public, use the session, otherwise use neither but use storage.
I would use the route option, as you suggest. Using sessions is going to end up being very difficult to test, debug, extend in the future etc.