I am using the CDN import method for SDK v9. I would like to know, given that I have a JSON-serializable representation of a user object, how can I construct a user object, so that I can use it with methods like updateCurrentUser.
If there was a way that I could access the UserImpl class like you can with npm
import { UserImpl } from '#firebase/auth/internal';
I'd be able to do this. However, I am stuck with the CDN import method, which doesn't allow access to the UserImpl class.
I understand that this may be a strange question, but understand that the way this is set up, once the user logs in, its json representation is saved elsewhere and the user object itself is lost.
I guess a better question would be, how can I deserialize a user?
An important piece of information here is that I want to be able able to deserialize users that once logged in. At some point of the app's lifetime, a user logs in(multiple users might log in and out), the user object is lost, and its json representation is saved elsewhere. I need to be able to retrieve the user object from its json representation later.
A potential workaround that seems to work at first glance, is to save a few informations from the first user that ever logs in:
const userInfo = {}
Object.setPrototypeOf(userInfo.stsTokenManager, auth.currentUser.stsTokenManager.constructor.prototype)
userInfo._clone = auth.currentUser._clone;
userInfo.auth = auth.currentUser.auth;
//and then I apply this to any user json I need to later on
user._clone = userInfo._clone;
user.auth = userInfo.auth;
user.stsTokenManager = userInfo.stsTokenManager;
//if I add the _clone,auth and stsTokenManager,I don't get errors andthe
//user json seems to become a user object for all intents and purposes,
//however I don't know if this is very safe and works in all situations.
//would applying the same clone,auth and tokenManager to all json users
//work?
Unfortunately, using the firebase admin sdk is also not an option because this is a client side app.
Is there any better solution? Thank you for your time.
Related
I was trying to find a way to get a User object from a user's ID alone. Client#fetchUser() seemed to be what I was looking for, referring to this
older question.
However that function is no longer in the Discord.js Client Object Documentation
And I can't seem to find a way of doing what fetchUser() is supposed to do. I need to create User Object from User IDs because I'm retrieving saved user data and need to be able to send messages to the users I'm retrieving from save data.
There are 2 ways to go about doing this:
Getting the user from the client.users.cache collection
const user = client.users.cache.get(UserID)
Fetching the user using the fetch() method in the UserManager of client.users
const user = client.users.fetch(UserID)
It seems they merged the functionality of UserManager#fetch()
into what I was looking for, in which it is described as
Obtains a user from Discord, or the user cache if it's already available.
PARAMETER TYPE OPTIONAL DEFAULT DESCRIPTION
id Snowflake
ID of the user
cache boolean true
Whether to cache the new user object if it isn't already
Returns: Promise<User>
So it'll either grab the user from the cache by ID, or retrieve it from Discord if it's not in the cache. I'm guessing they did this to make this functionality more efficient.
I'm using the standard Email + Password auth-provider.
Through certain circumstances I have to create a firebase user manually. The flow would be something like calling a REST api with an defined email + generated password, and if succeeded sending a welcome email to the user with his password. Something like forward user registration.
I read through their docs and couldn't find much. (the new docs don't even offer a REST API section for user management.. well and just to be clear, the new "google" styled docs, pretty much suck anyway :) ).
Is there someone who has already done something similar and can help me out?
BTW: It would also be possible to create them client side through createUserWithEmailAndPassword(), but this function does automatically reauthenticate the new user, which must not happen in my scenario. Is it possible to use createUserWithEmailAndPassword() without automatically logging in the user?
You can create a new Firebase App context in your client and then call createUserWithEmailAndPassword() there:
var authApp = firebase.initializeApp({
// ...
}, 'authApp');
var detachedAuth = authApp.auth();
detachedAuth.createUserWithEmailAndPassword('foo#example.com', 'asuperrandompassword');
By adding a second argument to initializeApp you create a separate context that will not trigger re-authentication upon user creation.
I'd like to add a property to a Firebase user object. The user documentation says that I can only store additional properties using the Firebase real time database.
I am unsure on how this can works in practice.
What does the following mean in practice?
You cannot add other properties to the Firebase User object directly;
instead, you can store the additional properties in your Firebase
Realtime Database.
I interpret it as following:
"you cannot modify properties of a FIRUser object but you can combine this with additional objects"
I found the set function documentation which I interpet in this way:
var userRef = ref.child("users");
userRef.set({
newfield: "value"
});
Is this a sensible approach?
You're almost there. In the legacy Firebase documentation, we had a section on storing such additional user data.
The key is to store the additional information under the user's uid:
let newUser = [
"provider": authData.provider,
"displayName": authData.providerData["displayName"] as? NSString as? String
]
// Create a child path with a key set to the uid underneath the "users" node
// This creates a URL path like the following:
// - https://<YOUR-FIREBASE-APP>.firebaseio.com/users/<uid>
ref.childByAppendingPath("users")
.childByAppendingPath(authData.uid).setValue(newUser)
I've added a note that we should add this information in the new documentation too. We just need to find a good spot for it.
According to the Custom Claims documentation,
The Firebase Admin SDK supports defining custom attributes on user accounts. [...] User roles can be defined for the following common cases:
Add an additional identifier on a user. For example, a Firebase user could map to a different UID in another system.
[...] Custom claims payload must not exceed 1000 bytes.
However, do this only for authentication-related user data, not for general profile information, per the Best Practices:
Custom claims are only used to provide access control. They are not designed to store additional data (such as profile and other custom data). While this may seem like a convenient mechanism to do so, it is strongly discouraged as these claims are stored in the ID token and could cause performance issues because all authenticated requests always contain a Firebase ID token corresponding to the signed in user.
Use custom claims to store data for controlling user access only. All other data should be stored separately via the real-time database or other server side storage.
Background: Using MEAN stack to build a web app, I am still learning.
The Issue: I find the following confusing. Say I have a user logged in (I am using Passport.js). From Angular I can retrieve it querying my Node.js server.
What I am doing now is something similar to:
app.get('/userLogged',function(req,res){
res.json({req.user});
});
This does not sound safe to me. I might be a novice, but I have seen this in many tutorials. With a console.log in the browser I can print all the info about the user, including the hashed password. My guess is that I should send a minimal set of information to the browser, filtering out the rest.
My Question: is this safe at all, or I am just leaving the door open to hackers?
Take a look at the concept of ViewModel. It represents the data you want to share publicly with an external user of the system.
What can be achieved in your case, is implementing the right view model out of the data model you store internally. A simplistic example illustrating this concept would be to create a view model for your user object that will pick the data you would like to send back :
// This function will return a different version
// of the `user` object having only a `name`
// and an `email` attribute.
var makeViewModel = function (user) {
return _.pick(user, ['name', 'email']);
}
You will then be able to construct the right view model on demand :
app.get('/user',function (req,res){
res.json(makeViewModel(req.user));
});
I am using Parse.com with my iPhone app.
I ran into a problem earlier where I was trying to add the currently logged in user to another user's PFRelation key/column called "friendsRelation" which is basically the friends list.
The only problem, is that you are not allowed to save changes to any other users besides the one that is currently logged in.
I then learned, that there is a workaround you can use, using the "master key" with Parse Cloud Code.
I ended up adding the code here to my Parse Cloud Code: https://stackoverflow.com/a/18651564/3344977
This works great and I can successfully test this and add an NSString to a string column/key in the Parse database.
However, I do not know how to modify the Parse Cloud Code to let me add a user to another user's PFRelation column/key.
I have been trying everything for the past 2 hours with the above Parse Cloud Code I linked to and could not get anything to work, and then I realized that my problem is with the actual cloud code, not with how I'm trying to use it in xcode, because like I said I can get it to successfully add an NSString object for testing purposes.
My problem is that I do not know javascript and don't understand the syntax, so I don't know how to change the Cloud Code which is written in javascript.
I need to edit the Parse Cloud Code that I linked to above, which I will also paste below at the end of this question, so that I can add the currently logged in PFUser object to another user's PFRelation key/column.
The code that I would use to do this in objective-c would be:
[friendsRelation addObject:user];
So I am pretty sure it is the same as just adding an object to an array, but like I said I don't know how to modify the Parse Cloud Code because it's in javascript.
Here is the Parse Cloud Code:
Parse.Cloud.define('editUser', function(request, response) {
var userId = request.params.userId,
newColText = request.params.newColText;
var User = Parse.Object.extend('_User'),
user = new User({ objectId: userId });
user.set('new_col', newColText);
Parse.Cloud.useMasterKey();
user.save().then(function(user) {
response.success(user);
}, function(error) {
response.error(error)
});
});
And then here is how I would use it in xcode using objective-c:
[PFCloud callFunction:#"editUser" withParameters:#{
#"userId": #"someuseridhere",
#"newColText": #"new text!"
}];
Now it just needs to be modified for adding the current PFUser to another user's PFRelation column/key, which I am pretty sure is technically just adding an object to an array.
This should be fairly simple for someone familiar with javascript, so I really appreciate the help.
Thank you.
I would recommend that you rethink your data model, and extract the followings out of the user table. When you plan a data model, especially for a NoSQL database, you should think about your queries first and plan your structure around that. This is especially true for mobile applications, as server connections are costly and often introduces latency issues if your app performs lots of connections.
Storing followings in the user class makes it easy to find who a person is following. But how would you solve the task of finding all users who follow YOU? You would have to check all users if you are in their followings relation. That would not be an efficient query, and it does not scale well.
When planning a social application, you should build for scalabilty. I don't know what kind of social app you are building, but imagine if the app went ballistic and became a rapidly growing success. If you didn't build for scalability, it would quickly fall apart, and you stood the chance of losing everything because the app suddenly became sluggish and therefore unusable (people have almost zero tolerance for waiting on mobile apps).
Forget all previous prioities about consistency and normalization, and design for scalability.
For storing followings and followers, use a separate "table" (Parse class) for each of those two. For each user, store an array of all usernames (or their objectId) they follow. Do the same for followers. This means that when YOU choose to follow someone, TWO tables need to be updated: you add the other user's username to the array of who you follow (in the followings table), and you also add YOUR username to the array of the other user's followers table.
Using this method, getting a list of followers and followings is extremely fast.
Have a look at this example implementation of Twitter for the Cassandra NoSQL database:
https://github.com/twissandra/twissandra