I'm a relative MVC noob coming from WebForms. I think I have a pretty good grasp of MVC with a couple exceptions, and I think I may have broken the pattern. I'm gonna try to keep this short, so I'm assuming that most of what I am asking is relatively obvious.
Let's say I have a news site with articles. In that case, a URL in the form of mynewssite.com/Articles/123 works just great because I don't care who views which article. The user can change the ArticleID in the URL to whatever they want and pull up that article. In my case, however, I only want the user to be able to view/edit data entities (articles, or whatever) that belong to them. To achieve this, I am using their UserID (GUID) as a foreign key in the database, and displaying a list of their data for them to choose from. Here comes the problem... when they click on the link that is created by Url.Action("Edit", New With {.id = item.id}) (I'm not using ActionLink because I need to add HTML content inside the link), the id shows up as a querystring parameter. I could add a route for it, but the id would still show up in the URL for them to tamper with. The obvious implication is that by tampering with the URL, they could view/edit any entity that they want.
What am I missing?
Is there a good way to pass the parameters without adding them on the URL? I know that I could put them in a form on the page and submit the form, but that seems cumbersome for my example, and I'm using jQuery.ajax in places that seems to conflict with this idea.
I could also check their UserID against the data in the Edit method, but that also seems cumbersome, too.
Is this question too broad? Please let me know what specifics you need. Thanks.
Even in Winforms, you would have to add special logic on each request to filter only the articles that the user owns. I don't see why MVC should be any different. Sure, you can use web.config to deny access to given url's, but not when you use a single page that takes a parameter of what data to show.
Your best bet is probably to filter this at the database level. By adding a where clause that includes the user id, then the app will return a "no records found" sort of error, and you can do whatever you want with it.
You could use forms authentication. This way when the user authenticates an encrypted cookie will be emitted which will contain his username which cannot be tampered with. Then you could verify whether the currently connected user has authorizations to edit this article.
Related
In my mod_perl2 app, on one page I link to with ?form_field_name=pre_fill_value tacked onto the URI if I want to pre-fill a particular form field for the user. However, the form itself is just <form method=post>, which posts back to the current page, GET query and all. I expected that Apache2::Request's param() routine would serve up either only the POST data, or the POST data first. Instead, it seems the GET data is given precedence, i.e., the prefill is honoured over the manually-user-fixed data.
The easy fix is to add action= and the current URI without the GET query, but I'm wondering why it was designed this way, and if there's a sneaky way around it, like some mod_perl2 option that would give POST data precedence. However, the easy fix can actually cause problems if un-overridden GET query values are expected to be passed on. So this workaround quickly grows, but why is it even this way in the first place?
My web site has a design where a grid of records is shown. For each record the user might edit it (a GET request) or change its status (this should be a PUT). Do I have a way of doing this without using Javascript?
That is, my current options are:
Use Javascript in a link handler to change the request type as needed.
Separate the GET and PUT activities to separate web pages.
Do the status change via a GET and turn a blind eye to REST specifications right here.
Are there other options?
Thanks,
Jerome.
A GET should not have any side-effects and a PUT would replace the whole resource at the location given by the URI. So the former should be a POST. The latter should be as well, unless it does in fact send the whole resource. A POST is possible without Javascript, obviously.
I want to set up a login page in which from anywhere on the site I can send a user to it and it will display a custom message along with it. I could use a redirect and a msg query param but is this the best way to do it?
I'm working with node.js but I'm interested in a universal solution.
If you are going for easy, you can just have GET data in the URL. But, that doesn't look that nice, if you want a rather long message, plus, GET has size restrictions, where POST (virtually) hasn't.
For using post data you could use the solution of this: JavaScript post request like a form submit question, but that gives a rather messy source code (if you want a somewhat longer text).
You could keep them in a database, and only send the ID of the message to a PHP page, and get it from the database (that's what I would do, but that doesn't mean it's a good idea, just amateur here!)
You can use jQuery or simply plain javascript to extract your message from the url; the relevant question that listed links to detailed code: jquery get querystring from URL.
Then depending on how you want it displayed, apply the extracted string to your situation.
When I GET from http://example.com/organization/ I get a list of organizations.
When I GET from http://example.com/organization/xyz/ I get the record for the organization xyz.
When I POST form data to http://example.com/organization/ I create a new organization.
What URL should I use to GET a form to fill out to create a new organization via a POST to http://example.com/organization/?
Looking at How to do a RESTful request for an edit form? and other sources, it would seem that I am really looking for a form resource for organizations -- so I should GET that form at something like http://example.com/organization/form/ and POST to http://example.com/organization/ as described above. This seems...untidy though.
Update
tuespetre's comments have me thinking the best way to do this is to have a form resource. The organziation form is provided via a GET to /form/organization/ which is filled out and posted to /organization/.
A form in the sense that you speak of one is not a resource, but a template to gather user input to POST a new resource.
One really 'RESTful way' to do it would be to utilize some Javascript to 'include' that form in the collection page /organizations, either as a hidden 'slide-down' form or maybe a modal dialog that appears when a certain call to action button is pressed. This would make semantic sense for two reasons:
You won't have to have some arbitrary URI being used for the form (which is not really a resource in the sense that your domain objects are), and
the 'create' form is for POSTing to the collection, so it really closely relates to that collection and thus would not be at all out of place to have right there with the collection.
Of course, you will find many opinions on this, but I would rather not have arbitrary URIs that break the established pattern (i.e., you're not getting an organization with an id of 'new', so why have that inconsistency?)
If you're trying to implement it, I've seen it done in different ways and I don't think there's a rule (but there are different patterns/approachs that you could follow or not).
I would make it http://example.com/organization/new/
If you are developing multiple modules on a webpage displaying different things such as content like a bio or pictures based on a userId passed through the Query String.
At page load should all modules on the webpage act independently and individually look at the query string and return the content based on the userId.
And in the same way should the modules individually check if the correct user is logged in before they are allowed to modify the content.
I have made a one or two modules before for a website but this is the first time I am developing a DotNetNuke website and I am just unsure if this is the only way.
Your user control should already inherit from DotNetNuke.Entities.Modules.PortalModuleBase. If so, you can use the this.UserInfo.UserID property to retrieve the User's ID. This will be much safer than looking at the query string. Remember that the user may not be logged in, and in that case the above would cause a null reference - so be sure to test for null first.
Also, on a somewhat related note, you can use this.UserInfo.IsInRole("RoleName") to test to see if a particular user is in a given role.
Each module should work independently of the other ones.
Also, I don't think you should look at the querystring to get your user id because that can be spoofed. Instead, look at the base class for your module to see if there is a property containing the user info.