So I am writing an app in Rails 5, and I am interested in the security issues of a simple feature I am trying to write. Users make Picks, which are secret from one another until a certain time. If I pass:
#picks = Pick.all
which contains everyones picks,
to the view with the controller, and then filter what is displayed depending on who the user is on the view, would a user be able to access that #picks variable using nefarious methods? At first I thought yes, but now I am thinking that the user just gets the raw view sent with no #picks variable. Unless users can sneaky dev their own html views?
Disregard that it's probably a better idea to do the filtering in the controller anyway, I just want to see if you can expose variables if you give them in full to the view and then filter them there.
Short Answer:
No, the client cannot access the #picks variable directly. Your view would have to display the value of #picks in the view in order for the browser to receive it.
Long Answer:
However, it would be good practice to limit the data assigned to #picks before it gets to the view. As your codebase grows and ages, and perhaps other developers start maintaining it, you may not remember that the #picks variable contains data that should not be displayed in the view.
Six months down the road, when the client wants to update the view based on new feature enhancement, you do not want to rely on the developer who is modifying the view to know that #picks contains sensitive data.
Make life easy on future developers (including you) by restricting the content of #picks to those records that the user is allowed to see at the time. Using the code suggested in the comments is a good idea:
#picks = current_user.picks
Or better yet, add a method to your model that contains the business logic for determining which picks are available to the user at a given time:
class User < ApplicationRecord
...
def authorized_picks
# code that returns the picks this user is allowed to see right now
end
...
end
And then your controller code is:
#picks = current_user.authorized_picks
That way all of your business logic is in the model, where it belongs 90% of the time. This also allows you to keep your code DRY by having the authorization logic all in one place.
Keep your code simple and DRY and you will thank yourself down the road.
No, They won't be able to get the instance variable which we use in haml/erb files. They just get the raw html.
As Ruby on rails does server rendering, all instance variables will be used to prepare view at the server side.
Anyways filtering should be done on controller side as best practice.
Related
I'm endeavoring to learn rails and am doing so by completing some super basic projects. The current thing I'm working on is a higher-lower game - the user guesses a number, and the server checks the guess against a randomly generated secret number, and responds if the guess is 'higher' or 'lower' than the actual number.
I've got most of the game complete, but I've realized I have no idea how to actually implement notifying the user if the guess was too high or too low. Other view changes in the game are handled by rendering a whole other page, but for this one I wish to display new text in the current page.
This question isn't really to solve my problem per se, I'm just trying to get pointed in the right general direction with controller-view interactions such as these.
Currently the only way I can think to do this is
Logic in the View
Make the data of whether the user guessed higher or lower available by using an instance variable, then use ruby in the html.erb view to determine what text to display based off this.
This seems ... dumb, and in violation of things I've learned about MVC in the past. Any other suggestions would be appreciated.
The cleanest way to do this in the "Rails" way would be to have a new path in your controller, for example show_result, and render a javascript view (show_result.js.erb). Then use a simple line of javascript to update the current DOM. Remember to set your form submission or your link to :remote => true and you're good to go.
i want to make a sequence diagram, which shows the login process in an .Net MVC Webapp (i.e. webshop).
I am quite new to UML modeling, so i am not sure, how to build the interaction between, Controller, model and view. I found different solution online.
Here are some question i have:
Does the client interact with the view, or directly with the Controller (in my test Trial the client interacts with the Controller)?
For the loginvalidation: In my test Trial the Controller ask the model, if the login_data (username and pw) are correct. Is it necessary, that the model interacts with an database, where the user data are stored?
If i would like to send data in an http Request, should i just add the variable in the brackets?
Here is my test Trial:
This is perfect. You just could shortcut the http-response and move it outside the alt fragment.
The controller is the one to "do the job" and the view just to present it. Actually there's a bit of intermix since views contain some basic I/O logic. But here the http-data travel from the client to the controller.
It depends. You "can" show that but you "must not". If the model reader needs to know the details you can show that directly or in a separate SD.
You would usually pass data as parameter of a method. You can also show concrete data (e.g. a quoted string or an integer value).
I have a Swift application i'm working on that allows a user to save various settings about their profile. Throughout my code, there are times where knowing these settings/preferences are important for the application's business logic. One of them is where the user works (their job, (which is a row in a sqllite database that has an ID as a primary key). The user is allowed to select one (and only one) in the app at any given time. Think of it like a profile - they can work many jobs, but only have one selected.
The following are scenarios where knowing the workplaceid profile is important:
In my sqllite database, retrieving work/shift information based upon the currently selected work ID(so not the ID from the database, but the ID they currently have selected). I'm passing this into my query.
In an NSDate extension function, when I go to determine some things about their starting date, I need to retrieve their currently selected profile, and use that for the calculation.
Within a particular view model when I want to show/hide certain fields.
On an alert view to show something related to their current workplace.
Now I think the quick and dirty way to do this is simply create a wrapper class to your nsuserdefaults in a utility class. Sure, all your info is stored in sqllite, but your currently selected app preferences are in nsuserdefaults since I can change this around (and it will change). This would parallel my other cross-cutting concerns such as logging/error handling, where I could use similar utility classes for all my work.
The fact that I might call this helper/utility class from every single layer of my application seems like a typical red flag you wouldn't do. Whether it's logging, or a user service to get information.
I'm curious to know what other people are doing in scenarios like this. When you need nsuserdefaults from all over your app, is the answer "eh who cares, just make a utility class and call it wherever you need it" ? Or is there a best practice others have followed with well-designed iOS apps? I know AOP is something folks tend to recommend. Does that have a place in iOS?
Thanks so much stackoverflow :)
The user is allowed to select one (and only one) in the app at any given time.
This tells me you want to create a singleton class. Every time you want to change the profile, you hit the singleton class and set it. That class encapsulates all the logic to get/set whatever you need, and the accessor functions. That's what I've been doing in my ObjC code for many years, and it has served me well. It's extremely easy to debug, and the rest of the code needs to know nothing about profile management (unless it's the UI part where you choose a profile).
I have an application that has different data sets depending on which company the user has currently selected (dropdown box on sidebar currently used to set a session variable).
My client has expressed a desire to have the ability to work on multiple different data sets from a single browser simultaneously. Hence, sessions no longer cut it.
Googling seems to imply get or post data along with every request is the way, which was my first guess. Is there a better/easier/rails way to achieve this?
You have a few options here, but as you point out, the session system won't work for you since it is global across all instances of the same browser.
The standard approach is to add something to the URL that identifies the context in which to execute. This could be as simple as a prefix like /companyx/users instead of /users where you're fetching the company slug and using that as a scope. Generally you do this by having a controller base class that does this work for you, then inherit from that for all other controllers that will be affected the same way.
Another approach is to move the company identifying component from the URL to the host name. This is common amongst software-as-a-service providers because it makes sharding your application much easier. Instead of myapp.com/companyx/users you'd have companyx.myapp.com/users. This has the advantage of preserving the existing URL structure, and when you have large amounts of data, you can partition your app by customer into different databases without a lot of headache.
The answer you found with tagging all the URLs using a GET token or a POST field is not going to work very well. For one, it's messy, and secondly, a site with every link being a POST is very annoying to work with as it makes navigating with the back-button or forcing a reload troublesome. The reason it has seen use is because out of the box PHP and ASP do not have support routes, so people have had to make do.
You can create a temporary database table, or use a key-value database and store all data you need in it. The uniq key can be used as a window id. Furthermore, you have to add this window id to each link. So you can receive the corresponding data for each browser tab out of the database and store it in the session, object,...
If you have an object, lets say #data, you can store it in the database using Marshal.dump and get it back with Marshal.load.
I'm required to provide functions for both users and administrators to edit account and profile details in a web application. An example of a URL for the public side of these profiles is:
http://example.com/user/joe
I'm still torn between two ways to design these URLs. I've thought of either this:
http://example.com/user/joe/edit
Or something non-specific and separate to the profiles:
http://example.com/account
The benefit of the first one is that it allows administrators to do their job through the same functions. This avoids building a whole different backend specifically for administrators. I suppose the negative here is that I'd have to be careful with authorization and make sure nobody can edit what they are not supposed to edit.
The second is a more standard way of doing things, it'd turn out to be simpler and easier to secure, though it means a separate interface for administrative users.
What is SO's opinions on this? Are there any more pros/cons for either way? Which method would you recommend to use?
I would have a different view for the administrator with such a security sensitive area. It makes things much more explicit having a separate view. It is likely even an administrator would only be able to edit certain user information and thus have a different view to the user editing themselves.
It makes the authorization much clearer even if the two views shared a common edit form
If you are using an MVC approach, then my suggestion would be:
http://example.com/user/edit/1234
or
http://example.com/user/edit/joe
Where user is the controller, edit the controller method and 1234 or joe the user id or username respectively.
But as Gumbo commented, administrators should not be allowed to edit user information. They should have some mecanism to disable the account in case of a profile has offensive content or false info. Forcing the user to update it to get the account active again.
The way we do it is the admin and the user share the same view. Items which are admin-only are protected from editing or viewing by the user.
The reason for the single view is:
It reduces the number of 'moving parts' - when a new field is added to the user screen, it only needs to be added once,
It is easier to move items to/from the user's purview. If all of a sudden, management decides to allow a user to manage their "FizzBar" then we only need make the change in one place, and
It is easier to segregate the roles and the functions at the controller level.
I think that you should go with the second approach. It's more secure and flexible, and shouldn't be harder to code than profile editing the profile inline.