Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm still learning Rails and how to best design my resource structure. Could someone help me with this? Here's my problem:
I am designing a specialized social network with profiles - every account has one profile. At the moment, an Account stores basic info about the user (username, password, etc.) from when they first sign up. A Profile stores other thinks like a picture link, answers to personality questions (linked back to a Profile via foreign key), and maybe more in the future. There is a one-to-one relationship between Account and Profile. Users can view/edit their own profile and view profiles belonging to others.
My questions:
Is it a good idea to split these two into separate resources altogether (i.e. have two different models) or collapse them into one model with two controllers? I have tried the latter, and it almost seems like more trouble than it's worth. Am I, in this case, fighting against the framework? I'm not sure yet whether users should be able to have more than one account in the future.
If I do split them, should I use a singular or plural resource for the profile? I noticed in the language at guide.rubyonrails.org that get (show) and put (update) work with the ONE and ONLY profile resource. My question with respect to my current situation is: "one and only" with respect to what? The "one and only" profile for the current user's account or with respect to the entire site? If so, how could I have the current user view profiles of other users - should I use a URL parameter like so:
http://www.example.com/profile?id=x, where x is the other user's account id
If I go the plural route, does index showing "all profiles" intend to mean all for the current user or for everyone across the site? Or is this up to my own interpretation?
I would appreciate any help I can get with this, as I feel like I am starting to understand REST and RoR conceptually but am just trying to put it into practice. Thanks!
I would personally keep Account and profile as two separate resources or at the lest 2 separate controllers accessing different parts of the same model.
This allows easy routes like http://www.example.com/profiles/2 for viewing other users and http://www.example.com/accounts/2 for managing your own account without having to add custom routes.
If you have the possibility of adding more profiles to an account, then this is a form of future proofing too.
Related
I have a question for a project I am working on. I am working on a RoR project in which a site is selling a single type of item, a book. The person I am creating this for does not want to deal with users creating user account to check out as the sales season is very short for this product, the purchases are done once per year, and the site only sells a single item.
I am wondering if there is something wrong with the implementation I am thinking of. What I was envisioning was a single database class called Orders. visitors to the site would simple fill out an order form with payment details through stripe and click submit. If they payment clears, the order with all the Orders information would be persisted to the DB. If the payment fails then it is not persisted and the relevant error information is displayed in using flash.
I suppose the meat of my question is; is there anything inherently 'wrong' about implementing this model without a users class and just having visitors to the site place orders?
I am a fairly new developer and this is my first big project so any feedback is appreciated!
If your requirements say that it is okay, then it is okay, if your requirements say it is not okay, then it is not okay.
There's not more to say, since only you know what your requirements are.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
This might be an unusual situation and a tough question to word, so bear with me.
Let's say I'm representing an enormous house in my Rails app. The house is made up of Rooms and Doors. Room and Door are my models. The house could have thousands of rooms and doors.
But I -- the developer -- want to predefine all the rooms, doors, and their relationships to each other. I want to define them programmatically, not let users make them. When the app launches, all of these rooms and doors exist. Users can then modify them in some ways, like changing the paint color or locking a door.
So rooms and doors can have state. But the layout of the house is predefined. So are the names of the rooms, and which doors are in a room.
What I'm looking for:
I write the code and/or markup that defines the rooms and doors, their layout, and their default state. The rooms and doors can all have their own methods and functionality.
Modifications made to rooms and doors by users -- like locking a door or changing the paint color of a room -- are stored in state (ActiveRecord). This state could be reset by me, the developer, to the default state I built the room or door in.
I could develop new rooms and doors in the future, releasing them in a new version of the app.
How could I go about achieving something like this?
What you are describing is essentially just an normal application (Rails or any other kind). You define your entities (models), the attributes they have, and the relationships between them. Which kinds of entities users can create/delete versus simply change attributes is a choice you make when you create the user interface.
The question is too broad to cover in detail, but a couple of the things you specifically asked about in Rails terms:
You can use the db/seeds.rb
file and rails db:seed task to populate your database to a
specific known state once you've defined your models. Resetting to that state is as simple as dropping the tables and re-running db:seed. It's also relatively easy to write scripts/tasks that bulk update data without forcing a complete reset of the database. The same is true for adding additional pre-defined data.
When you create routes for your resources (config/routes.rb) Rails by default creates routes/actions for all CRUD (CReate/Update/Delete) actions. But, it's simple to override that behaviour and only create the routes/actions that are appropriate for that type:
resources :rooms, only: [:index, :edit, :update]
I'm trying to build a question and answer flow in a Rails app, and I need to be able to add new Questions to the Questions model, but have them available to any user of the app, not just the User who submitted the questions in the first place.
As it stands I've got the authentication built from the Hartl course - with one addition myself (the first user to sign in is an admin for an "Organization" and can add more users to that Organization). This means that any User who belongs_to that Organization can see their related models and collaborate within the app, but a User from another Organization cannot see or interact with anything but their own data.
What I need now is the ability to add Questions to a Question model (Question belongs_to Organization) - but I'd like these to be Globally available (so the question set is built up over time, and Admin users can select questions that are important to their Users, but ignore other questions that are less relevant).
Is this possible in Rails? I presume I'd need to create a new class or something like that, but I don't really know what question to type into Google to get me on the right path.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I am fairly new to MVC and am interested in keeping my MVC app secure. One of my concern areas, for example, is an Approve page that is available to uses to approve items that are up for review. The issue is that certain users can only approve certain items. When approving the app posts the ID of the item being approved to an ApproveItem ActionResult in the controller. The issue is that in theory (e.g. with FireBug) someone might post random IDs to this ApproveItem controller (including items that they might not be allowed to approve). Instead of trying to catch every issue like this in filtering, why not just use a GUID as the ID? Then I am almost 100% certain that the user is only approving an item that they are allowed to approve.
What do you guys use for security in regard to situations like this? It seems to me that a GUID would be the simplest. What do you think?
Your question (or at least the tile) doesn't really make sense. You can use Guids for Globally Unique Identifers within a security system, but you shouldn't use them AS the security system.
#ePezhman alludes to a potential Insecure Direct Object Reference vulnerability but this isn't an issue if you are correctly validating your users` actions.
What you're suggesting is Security through obscurity. Your app isn't actually secure, it's just really hard to guess some naughty input. What you should be doing is what you're trying to avoid and validate that the current user has the required permissions to perform the action on the entity. That is, is the user allowed to approve the item? and if they aren't you should display an error message or take other appropriate action (logging the attempt, notifying an administrator etc?).
GUID will be very simplest way to achieve this.
Otherwise you can go for "person -roles " level security to approve your items.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
So I have this web app that in theory may one day become a for-pay application - if anyone actually finds it useful and worth it.
I have all the logic to handle payment, check to see if the account is overdue etc. in place. It is all stored in RavenDB (RavenHQ actually) - not that this should matter to the question at hand.
Now, I am trying to follow best practices, and I want my application to be performant, i.e. not micro-optimizing, but I want to do things in a way that will scale relatively well with load (if it takes off it will be hosted - I would love to not have to pay for more servers than is strictly necessary).
My app uses something close to the default login/account model. Users log in securely using forms authentication over https.
At what point should I check that a user is actually allowed (with regards to payment status etc - a domain model concern really) to be using the web application? Consider that this will mean requesting a single document from the RavenDB backend and checking if the current payment period has expired.
Should I:
Check every time the user logs in, and make them unable to "Remember me" for more than x hours, where x is a relatively small number?
Check in a few central controller actions that the user would visit relatively often - the application would essentially be severely restricted if these actions were not available.
Do a global action filter that checks for every request, then redirects to the "Pay nooooow!" page as soon as stuff expires?
Another option?
RavenDB does clever caching, so I don't think a request for this document would kill performance, but should the application really take off (unlikely, but one can dream), an extra database request per http request will probably lead to Ayende hunting me down and mercilessly beating me. I don't want that.
It seems to me like this is something that others would have thought about and solved, so I am asking - what would be the right way to handle this?
Thanks for any insights!
I don't think this is a framework issue strictly, it's more like how you want your site to behave and then use framework to support it. Generally speaking you want to make the site usable and not too restrictive unless when that's necessary, e.g. surfing the site with no restriction whatsoever, but checking out should be done very securely.