Updating Meteor.users - meteor

I've created a form for users to update their profiles. When I submit the form I'm receiving a [403] error.
Not permitted. Untrusted code may only update documents by ID.
My question is, if I'm going to use Meteor.users.allow, where - in what file/directory - do I write this code?
Thanks,
Nathan

The error you're getting is not a result of your allow/deny rules. You would get a straight 'Access Denied' error if it were.
When updating your users (as well as having the correct allow rules in place) you need to update your user by their _id- especially if they are being updated on the client end.
So instead of
Meteor.users.update({name: "etc"}, {$set:..});
You need to split it in two, one to get the _id and then one to update your document on that.
var user = Meteor.users.findOne({name: 'etc'});
Meteor.users.update({_id: user._id}, {$set:..});
The rule is on the client you can only use _id to find the document when updating.

Related

Is there a way with Hasura to do a mutation based on the result of a query, within the same GraphQL call (Hasura transaction)?

I tried to search for an example but, I presume it's not doable. I am looking to hopefully be proven wrong or to find an official confirmation that it's not doable.
Before using Hasura, I was doing transactional SQL queries that ensured that data was kept consistent.
For example, I would like to create a password reset token if a user requests it, only if the user can be found using an email address. Right now, I have to do 2 queries:
Try to find a user with the specified email address
Insert and assign the token to this user id
In that case, it's not too bad, but now if I want to consume that token, I have to do 3 queries:
Find the valid token
Change the password to the user associated with that token
Delete the token
Obviously, if something goes wrong and the token is not deleted, this could be an issue - so I would be curious to see if there would be ways to merge these queries/mutations into transactions.
Sounds like supporting nested updates would solve this problem for you with the least amount of effort. We are working on a rfc for the feature and hope to start development soon. Please follow this Github issue on our community for future updates.
https://github.com/hasura/graphql-engine/issues/1573
This comment outlines the current scope of the proposed feature. The rfc will provide a more complete explanation.
https://github.com/hasura/graphql-engine/issues/1573#issuecomment-1338057350
You can apply changes to rows that you filter by certain criteria. Here is a sample mutation:
mutation PasswordUpdate($id: uuid!, $token: String!, $new_password: String!) {
update_user(
where: {id: {_eq: $id}, token: {_eq: $token}}
_set: {token: null, password: $new_password}
) {
affected_rows
}
}
That query deletes the token and sets a password for all users (hopefully just one) that have the token assigned.
After some research here is what I found:
For the first example:
Try to find a user with the specified email address
Insert and assign the token to this user id
There are no solutions for this today and as answered by #damel, there is an ongoing RFC to support nested mutations: https://github.com/hasura/graphql-engine/issues/1573#issuecomment-1338057350
Hopefully, this feature will be out soon, but in the meantime, for most cases, it's not such a big deal to have multiple queries as it is possible to catch errors on the first query.
For the second example:
Find the valid token
Change the password to the user associated with that token
Delete the token
When sending multiple mutations in the same query, Hasura treats them as a transaction as announced in 2020.
Of course, it would be nice to do this in the same query (similar to the first example) but since there is a transaction on the mutation, for this case it's still not a problem.
I am sure there are probably cases where this can become a problem but I am not exposed to them right now. Nevertheless, it would be great if the RFC makes it to production, giving more options to Hasura users.

Request.auth.metadata in security rules?

I have a Firebase project where I'd like for users to be able to see when other users created their profiles. My initial hope was that I could use "user.metadata.creationTime" on the frontend to pass the date into the user's extra info document and verify that it is correct by having "request.resource.data.datecreated == request.auth.metadata.creationTime" as a Database Rule, but it looks like it is not possible according to the documentation.
Is there any way I can verify that the creation date is correct on the backend?
More info edit: Below is the code that is being triggered when a user creates a new account on my profile. The three values are displayed publicly. I'm creating a niche gear for sale page so being able to see when a user first created their account could be helpful when deciding if a seller is sketchy. I don't want someone to be able to make it seem like they have been around for longer than they have been.
db.collection('users').doc(user.uid).set({
username: "Username-156135",
bio: "Add a bio",
created: user.metadata.creationTime
});
Firestore rules:
match /users/{id} {
allow get;
allow create, update: if request.resource.data.username is string &&
request.resource.data.bio is string &&
request.resource.data.created == request.auth.metadata.creationTime;
}
user.metadata.creationTime, according to the API documentation is a string with no documented format. I suggest not using it. In fact, what you're trying to do seems impossible since that value isn't available in the API documentation for request.auth.
What I suggest you do instead is use a Firebase Auth onCreate trigger with Cloud Functions to automatically create that document with the current time as a proper timestamp. Then, in security rules, I wouldn't even give the user the ability to change that field, so you can be sure it was only ever set accurately by the trigger. You might be interested in this solution overall.

Unable to base security rule condition on resource data in Firebase

I am attempting very simple thing and that is matching request.auth.uid to a field value in my transaction documents (like this resource.data.useruid) in Firebase security rule in order to get transactions of a particular logged in user. However, I don't get any documents while querying for them and get an error instead.
This is how the collection looks like - just one document there with useruid field.
The field's value is mapped to the users uid (screenshot taken in the Authentication -> Users tab.
And the rule looks like this
I should get the one document back but every time I query the documents with that user logged in (I am using angularfire2 for those purposes) I get Error: Missing or insufficient permissions.
If I modify the rule condition to return always true or if I only check for truthiness of request.auth.uid I get the query result alright. The funny thing though is that with resource.data involved - eg. checking for value of the amount field in the firebase rule - the condition is never met. I tried to write it like
allow read, write: if resource.data.amount == 3
and got the error again. Seems like I don't get the resource.data Map at all.
I feel like I am missing something obvious, although after reading the guides, it seems alright to me and I am already out of ideas. The debugging capabilities (or lack of) make the whole process very slow.
Could you please explain to me, why I don't get the resource.data Map in the firebase security rule or point me to a place where the problem might be?
You have most probably missed one specific point in the doc: your query fails "because it does not include the same constraints as your security rules". See https://firebase.google.com/docs/firestore/security/rules-query#secure_and_query_documents_based_on_authuid
The following, with your security rules works perfectly:
firebase.auth().signInWithEmailAndPassword("xxxx#xxxx.com", "xxxxx")
.then(function (info) {
db.collection("transactions").where("userid", "==", info.uid).get().then(function(querySnapshot) {
querySnapshot.forEach(function(doc) {
console.log(doc.id, " => ", doc.data());
});
});
});
If you remove the where clause, you get the exact error you are getting

How can I attach a custom form to a Workfront user with the API?

I have a requirement to insert new Workfront users through the API, which I am able to do. However, I need to update a Custom Form item with an employee id. With a new user, the Custom Form must be attached before the employee id can be update. I am using the following url to attach the form:
https://<url>/attask/api/user/<userguid>?sessionID=<sessionid>&updates={'objectCategories':[{'categoryID': '225845d1800010d52527455df2a27f0fe2','categoryOrder':0,'objCode':'CTGY'}]}&method=put
The result is a HTTP Error 400: Bad Request
Is it even possible to attach a Custom Form to a user? Or is there another way that it can be done through the API?
For reference, I had to work through the exact same question. You are correct in your update that you need to use the most recent version of the API (as of this post, that would be 6.0) but for others who are wondering, the syntax is as follows:
https://<url>/attask/api/v6.0/USER/<userID>?apiKey=<key>&updates={"objectCategories":[{"categoryID":"<customFormID>","categoryOrder":0,"objCode":"CTGY"}]}&method=put

Creating a user failed. Is there a way to interogate the error?

I am using the ASP.NET Identity framework, with the EntityFramework provider (IdentityDbContext).
I attempt to create a user by calling UserManager.CreateAsync(..).
It returns an object of type IdentityResult, with the following values:
{
Succeeded: false,
Errors: ["Name AndrewShepherd is already taken."]
}
The error is valid - there is indeed another user called "AndrewShepherd" in the database. This is not a name the user picked; instead I am generating this name from the Outh2 account information provided by their Google account. (Google Accounts don't enforce unique names, just unique email addresses).
Since the problem is a duplicate name, I can simply try appending a number to the name and trying again. I would programmatically attempt to create AndrewShepherd_1, AndrewShepherd_2, AndrewShepherd_3 until I am either successful or get a different error.
But how do I programatically determine that the problem was a duplicate name?
Options are:
Perform a pattern match on the error string. This solution is guaranteed to break when the next version of ASP.NET Identity has a differently worded error messages or we internationalize the website.
Run the check before creating the user. I would call UserStore.FindByNameAsync to determine if the name had already been taken before invoking UserManager.CreateASync(..). This would have a small concurrency risk if two different sessions are attempting to add the same user name at the same time.
It would be some much easier if we could simply perform a check like this:
if(identityResult.Errors.Where(e => e.ErrorCode == IdentityErrors.DuplicateName).Any())
Is there a way I can perform a unique user check then add a user, that's safe in a concurrent environment?
As an alternaive, you can check if the user name is exist in your DB like that. If user name is already taken, you can change new user name like AndrewShepherd_1, AndrewShepherd_2, AndrewShepherd_3.
using (YourProjectName.Models.DefaultConnection db = new Models.DefaultConnection ())
{
if (db.AspNetUsers.Select(q => q.UserName).Contains("usernameThatYouWantToCheck"))
{
/*Your code*/
}
}

Resources