I have a question regarding some action accessing, i'm not talking here about authorization etc, but more about the direct access to actions.
Basically i have 2 question, 1 general and 1 more contextual:
Situation imaging i have an action : MyArticles/DeleteArticle/id
1) How can i prevent that if someone will just put this url with a proper id remove article? How can i say that it can only be used with a button on my website? And should this action be a get or post?
At this moment i use $.ajax and GET method ....
2) Now imagine i have many people, and if all th ppl are registered, they can delete each others article, what if i want to avoid that and let users only delete their own articles, because at this moment for example if they can guess the id they can directly access the action with id and delete it.
Can anyone provide explanation and some tips about that?
i'm not talking here about authorization etc
Yes, you are. The authorization to delete the article should take place within the action itself, it's not the responsibility of the calling code or of any UI which displays a link to the action.
How can i say that it can only be used with a button on my website?
I imagine any approach to that is going to complicate the issue tremendously. Understand how HTTP requests work... Your application isn't making the request to the action, the user is. They're doing so (in the general case) by clicking a link on an interface provided by your application, but the request itself is coming from the user. (Well, from the user's web browser, which is in their control and not yours.)
The most straightforward approach to this is to encapsulate authorization in the action itself (or, better still, in the model functionality being invoked by the action... but logically that's still part of the "request" being performed).
When you expose a piece of functionality which not everybody should be able to invoke, put the authorization on the functionality itself instead of on the UI which invokes it. That way no matter how it's invoked it always maintains the authorization, instead of just assuming that some other component maintained it.
You have a lot of control in MVC with respect to the USER. To allow a user to delete only his own work, you must remember in the database who wrote what. If this is the case - and you know it, a simple if statement in the beginning of the action will do the trick.
Related
Context:
I was going through various guides, tutorials and also posts here in the stackoverflow.
I need to handle process, e.g., - “pick topic —> show author list —> delete all —> ask confirmation —> show result —> go back to author list”
The obvious (and simplistic) approach is to create sets of views for each process.
And save process state in session variables or pass via URL-s (however, I discovered this method can be very brittle if too many information is passed). Also I need to tell each view where to go next, and this mushrooms into a bulky chain of instructions repeated for each URL request.
Instead, I want two extra things:
encapsulate a process at single place
re-use views, e.g. to re-use Topic List view to pick a single topic. That is, to work in “picker mode”. (btw, if I try to do this with multiple view classes, the next view class needs to know what to do and where to return…)
I also checked django workflow libs, and so on. and still not convinced.
Question:
if I create global object to encapsulate process and reference it from the current session - is this a good idea? My main concern is that - as sessions come and go, who will be cleaning up this global object?
is it possible to somehow make this clean up automatic? that is, when session goes away, some method is called where I can clean up or help GC to collect unneeded object? Like C++ destructors?
after working further with code, it occured to me that if I add global object to the session (and nowhere else) - it must be garbage collected in due course, because session itself is managed by Django.....
also, reading https://docs.djangoproject.com/en/3.1/topics/class-based-views/intro/ in my 3rd pass, found that Django's as_view() instatiates a new instance of class based views on each HTTP request.
so, everything is per request basis, and data will be transient. So only way to maintain state across HTTP requests is to either persist in the database or use sessions (or keep passing "state" from each request to request via URL parameters, but it is bulky, unsafe. my understanding is that this is a fallback mechanism if cookies are not allowed and session can be simulated via this way, e.g. PHP does it).
I am new to Django and want to know deeper about the concept of signals.
I know how it works but really don't understand when should one really use it.
From the doc it says 'They’re especially useful when many pieces of code may be interested in the same events.'
What are some real applications that use signals for its advantage?
e.x. I'm trying to make a phone verification after user signup. Because it can be integrated inside the single app and the event that interested for the signal is only this 'verify' function, therefore I don't really need signal. I can just pass the information from one view to the other, rather than using pre_save signal from the registration.
I'm sorry if my question is kind of basic. But I really want to know some insight what is the real application, in which many codes interested in one particular event and what are some trade off in my application.
Thanks!!
Often signals is used when you need to do some database-specific low-level stuff. For example, if you use ElasticSearch for better searching documents on your site, you may want to automatically update search indexes, when new document is created or old one was edited.
Also you may have some complex logic of managing database objects. For example, you may need some specific logic of deleting object. For example, when user is deleted, you may want change all the links to his profile by some placeholder, or when new message is created or other action is performed by user, you want to update "last visited" field in user's profile and there's no direct relation between this action and updating the profile.
But when you're just implementing business-logic as in your example with verification, you don't need to use signals, because you don't need any universal logic related to deleting/creating/editing any object: you have a certain object with which you work and can do stuff directly.
I am trying to detect a period of user inactivity in my EmberJS application so that, after a certain duration I can call a session.inValidate method and revoke their authentication.
The only resource I have been able to find is an article here which I was advised in an original question is out of date and doesn't use current Ember concepts.
The out-of-date article suggested adding a property to the App object and updating the property on certain events like mousemove but I was unable to find a location to set this property correctly in either app.js or the config environment.
ember-concurrency was recommended but after looking at some of the documentation I still don't understand where such code fits in an EmberJS application structure.
Unfortunately I'm stuck at a point before I can give a code sample. Any advice is appreciated.
Edit: As per #hernanvicente excellent question, I am defining inactivity as 'no user input'. So no mousemove or key press events within X period
The hard question here is what activity actually means. Generally I would advise against your idea. There is no way to know if the user is actually still looking on your page.
However if you really want to do something after the user hasn't done something for some amount of time the interesting question is where to place your code.
You have multiple options here, but probably not the worst option would be to use the application controller. You could also use a service, but then you need to use that service somewhere to initialize it. You could also just use a component.
If you want to couple this to authentication you could consider to use the existing session service.
However everything else is not really ember specific. You can just place some code in the application controllers init hook and access document.addEventListener(). Then you could just save a timestamp away and act accordingly.
To have a bit a nicer API for waiting you can utilize ember-concurrency with a restartable task:
didSomething: task(function * () {
yield timeout(1000); // number of miliseconds to wait
logout();
}).restartable(),
here logout() will be called, after the task hasn't been called for 1 second. A nice visual demonstration about task concurrency and restarable can be found here.
Here is an ember-twiddle showing a complete example.
I have got an architectural question. Where should I check user permissions for certain operations?
For example:
1) In a controller, I get parameters from view and start a process in the intermediate model.
2) Intermediate model decide which parameter should be converted and transformed in any way and modify or create data through Models
3) Model communicate directly with DataBase
Where do You think is the right place in that "architecture" to check privileges to for example save sth to database?
I would actually put the authorization check before the controller is being called, kinda like described here (I really need to update that old post). Preferably as a decorator around the controller instance, which would give you a fine-grained control over what operation user is permitted to do, based on controller+method pair.
Another point where you might think about is "authorization lookup" helper function for use in your templates, because you might need to show or hide some UI elements from users, who should not be able to perform the associated operations. The controller+method check, before execution would still work as the actual safeguard then, but it tends to be a quality-of-life improvement.
You should not put the authorization checks inside the each controller or (even worse) model layer, because that tends to promote an excessive amount of copy-paste, which in turn can cause mistakes and becomes a huge problem, when you want to alter the mechanics of your authorization system.
I need to create a one-to-one relationship between a Game and a Site - each game happens in one site. In my database, site is an attribute of the Game object which points to a Site object.
I couldn't find much on the internet about this, these are my ideas:
GET /game/<game_id>/site
Gets a game's site, hiding the site id.
POST /game/<game_id>/site
Creates a game's site, this is only used once when creating the game.
PUT /game/<game_id>/site
Updates a game's site
DELETE /game/<game_id>/site
Deletes a game's site.
But what if someone wants to get a list of all the sites? Should I add a /sites URI and have the get method for the Site object detect whether a game_id has been passed in? Should I also let people access a site by /sites/<site_id> Or should I let the client populate their own list of sites by iterating over all games? Finally, I usually have an 'href' attribute for each object which is a link back to itself. If I went with the above design (incl. the /sites/ URI), do I link to /game/<game_id>/site or /sites/<site_id>? Should there be two places to access the same info?
Am I on the right track? Or is there a better way to model one-to-one relationships in REST?
If it matters, I'm using Flask-RESTful to make my APIs.
Your ideas make a lot of sense.
The big distinction is whether or not a site can exist independently of a game. It sounds like it can. For example, two games may point to the same site.
As far as I understand with RESTful API design, there isn't a problem with exposing the same site resource through both /game/<game_id>/site and through /sites/<side_id>. But REST encourages you to link data through hypermedia.
Exposing the site in two different places could complicate things, since you'd then expect to be able to interact with site objects through both of those URLs.
My recommendation to keep your structure explicit and simple would be:
Have a collection of site resources at /sites
Expose site resources at /site/<site_id>
Use a link object from a game to a site. See Thoughts on RESTful API design by Geert Jansen.
Following the link object design, your game resource representation would include something like this:
{
"game_id": 10,
...,
"link": {
rel: resource/site
href: /api/sites/14
}
}
Without more design work, this would mean you'll make a second call to get the site's information. Every design has its compromises :)