I have an app where I want visitors to be able to write down some text.
They are the only ones that are allowed to see their own entries.
In order to allow people to create an entry I have set the security of the content type: crud is permitted for those who have viewing rights.
In the query designer I have basically just the list of the content type. So, of course any visitor that can see the page, sees all entries.
How can I limit the results so the visitor only sees her/his own entries? If I add the ownerfilter in the query designer, the results come up empty.
So basically what you should do is give these permissions on the type:
Registered users (or those who may add) should have c permission (create). They must be logged in - so don't use "everybody" - otherwise you won't know who added it.
Owners (those who created the record) should have edit permission (I wouldn't give them delete)
In the visual query, you should then use the owner-permissions. As a host-user you can only test it, if you also made some records.
OK? otherwise just add more infos.
Or just add a field that stores the username. When you show the entries, only show the ones where the current username matches the username field :)
Related
I'm building a simple application where posts appear on a user's home page and he can like or unlike them.
first when there were no users in the applications, I made a simple boolean field "liked", as shown in the figure, to determine if a post is liked or un-liked. However, when I started working with users, I find it hard to find the perfect structure for the likes field.
In Firestore, I added a field named "likedBy" for each post, which contains a map with a key of each user's id and a boolean to determine if the user liked the post or not.
I don't know if this structure is suitable or not, and if not, is there a better way to reach my goal?
The likedBy field is enough to cover most use cases.
Just store in likedBy an array of all users who liked the post by user ID. When a user likes - add the user ID to the array and remove it upon unlike.
That means you can also remove the likes and liked field as you can get it from reading the likedBy array.
I would recommend going one step further and save more than the User ID. You could also save the User displayName and photoUrl. That way, you don't need to read ($$$$money$$$$) the documents of every Users who liked Posts in order to display their name and/or avatar.
In an MVC application I have a two pages process. On the first page we gather information that will allow us to identify which database record to update. On the second page we gather new values used to update this record. In order for this to work, we need a way to persists information between the two pages, including some record id.
I though of two way to do this and both have some problem.
Store the information in the Session object.
This works as long as the user does not open a second browser window or tab. If he does there is a risk that he'll apply the modifications to the wrong record. Suppose he opens tab 1 and complete the first step. Record id 1 is stored in the Session object. The user then open tab 2 and complete the first step. Record id 2 is then stored in the Session object overwriting record id 1. The user then come back to the first tab and complete the second step thinking he is editing record 1, but in fact he will be editing record 2.
Store the information in an hidden field on the page.
This would solve the problem solution 1 has, but it would be trivial for a ill-intentioned user to change the record id to overwrite any record.
While typing this question I just though of a third solution. That is an hybrid of theses two, but I'm not sure it's completely safe. We could store a random id in an hidden field on the page and use this to prefix the key we use to access data in the session object. I think this would work. Could this be exploited as solution 2 could?
Any other good way to securely store data "per tab" instead of "per session"?
Considering way 2 you may check security server side. If a user does not have modification rights on a specific record then server must not save it. Otherwise he/she is modifying a record that has modifications rights on it and does not matter if he/she is doing it by standard UI or hacking under it.
I think you are mixing up two things - authorization and passing data.
If user is authorized to do stuff with "another record", it's not important if he "tempers the hidden", because he is authorized to change another record as well. Nobody is going to do that intentionally. Means - you just need to check if user is authorized to do stuff in every post from the user i.e. in each controller method (and this is normal practice to always validate all user input server-side).
I would suggest you go with "hidden field".
If you want to separate info in different tabs you should use sessionStorage that differs for each open browser tab.
You can set it like this:
sessionStorage.setItem("perTabValue", "true");
Then you can get your value:
var x = sessionStorage.getItem("perTabValue");
if(x === "yourValue"){
//do anithing you want
}
In my project i am sending a mail to the user to create a user account. I want to enable that link for the first time he/she clicks the link. if he clicks the link for more than 2 times,then it should go to custom error page.how to do this?
This depends on how the link is generated.
For example: If your link contains a username as GET-parameter, then you could simply query your database if the username is already in use. I would advise against that, because the user can easily change that GET-Parameter
I would recommend this: Your link should contain a unique identifier, most likly a hash. This hash is stored somewhere, to garantee it's uniqueness, like in the usertable of your database (a column for the hash of the registration link). That might also come handy, because you could create new user rows and already prefill them with necessary information. You could use these information upon rendering to insert text into the textboxes
I have a normal Drupal User. I have used the content_profile module to create a profile content type. This content type contains a node reference to another content type company. The company node then references a type of node called Task.
I want to create a view that list all the tasks for a given user id.
So I imagine I would create a view with an argument of user id. Then I would add the relationship to the profile and the company and output the Task title.
The user id used seems to work on the created used ID and not the user id of the content profile that it is referencing. In our system the "admin" user creates the profiles so it causing some problems.
Any ideas? I feel I may need to write a custom module to do what I want.
i have answered a similar question in the past about how to create a view using part of the url as an argument to filter the view by the user profile. check out this url. the answer you are looking for may be a variation of my original response.
also, how are you creating those profiles? on one of my sites, when i created the profile page, its author ID is automatically changed to the user it is associated with.
I'm making a security permission system for a Dynamic Data site based on the article Securing Dynamic Data Preview 4 Refresh. The system contains an additional permission kind: "deny an operation for a record/field if a record is not owned by an user".
If an user can read only own objects, we need to have an always enabled filter in List and check permissions in Details. If an user can write only own objects, we need to check permissions in Edit and Delete, remove "Edit/Delete" links from some rows in List, make "User" field readonly and provide its value in Insert. I didn't think about column-level permissions of this kind yet.
So, the main problem, as I see at this moment: too many places to place the same checks (I didn't even think of malicious user crafting POST data). Also I couldn't make make a field in Insert at the same readonly and having a value which is displayed and saved to DB (I don't want to place that in the model partial classes because I think that there are already too many places that need to be edited to implement this functionality).
Is there a single place to deny a read or write operation with an object depending on the object value?
How can I provide a default value to the field, so that it will be shown on the Insert page, inserted to the DB and couldn't be changed by the user before inserting?
The following assumes you're using LINQ to SQL.
Is there a single place to deny a read
or write operation with an object
depending on the object value?
Reads
I know of no simpler way to restrict reads than to add a filter to all the relevant LinqDataSource controls. If you are able to implement your filter generally, you can write one QueryCreated handler, then add a single line registering your custom handler to all the page templates.
Writes
In the Dynamic Data metadata, add an OnValidate partial method to all the relevant tables. If the current user is not allowed to ChangeAction the given record, throw an exception. You will still have to update all the page templates to hide UI elements that the user does not have access to, but at least you can rest assured that the worst that could happen in some unexpected case is that the user sees an error page.
How can I provide a default value to
the field, so that it will be shown on
the Insert page, inserted to the DB
and couldn't be changed by the user
before inserting?
Perhaps look at some combination of adding an OnCreated and OnValidate partial methods. See also: this answer.