On Aug 5, 2007, at 7:42 AM, Hendy Irawan wrote:
> To add, shouldn't security/authorization be implemented mostly in the
> model?
Depends on the level you have to authorize on. I've never written an
application where is was necessary to drop down to model level to
ensure people didn't access
Brian Hogan wrote:
> Sure. Very much so... and that's exactly how I've been doing it. So
> what I understand is that it's perfectly fine to query the database
> that many times, because it's good for security and data integrity. I
> can live with that. Just wanted to make sure that was the bes
Those filters are easily memcached when you start hitting loads, and
are easily stubbed in your controller spec. You can also combine some
of those calls with an :include.
Also, some of the actual find_xx methods belong in application
controller.
---
Courtenay
On Aug 3, 2007, at 6:30
ha! Of course. That makes total sense. :) Wow. Sometimes it's right there in
front of you. Thanks a lot!
On 8/3/07, Tim Lucas <[EMAIL PROTECTED]> wrote:
>
>
> On 04/08/2007, at 8:39 AM, Brian Hogan wrote:
>
> > Indeed. I'd love to see examples of this proxy for authentication
> > for teams of whic
On 04/08/2007, at 8:39 AM, Brian Hogan wrote:
> Indeed. I'd love to see examples of this proxy for authentication
> for teams of which he speaks. :)
/projects/3/tasks/8/notes/2
class User < ActiveRecord::Base
has_many :roles
has_many :projects, :through => :roles
end
class Project < Ac
Indeed. I'd love to see examples of this proxy for authentication for teams
of which he speaks. :)
On 8/3/07, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
>
>
>
> On Aug 3, 2007, at 17:23 , Brian Hogan wrote:
>
> > Sure. Very much so... and that's exactly how I've been doing it.
> > So what I und
On Aug 3, 2007, at 17:23 , Brian Hogan wrote:
> Sure. Very much so... and that's exactly how I've been doing it.
> So what I understand is that it's perfectly fine to query the
> database that many times, because it's good for security and data
> integrity. I can live with that. Just want
I think nested routes are quite cool and useful, specially if instead
of using numerical IDS you use codes that have a meaning for the user
so
projects/2/tasks_category/3/task/5
becomes
projects/CoolWebApp/task_categories/design/tasks/user_profile
Such a url is hackable and meaningful, it's c
Sure. Very much so... and that's exactly how I've been doing it. So what I
understand is that it's perfectly fine to query the database that many
times, because it's good for security and data integrity. I can live with
that. Just wanted to make sure that was the best way to explain it to my
stude
On Aug 3, 2007, at 17:01 , Brian Hogan wrote:
> Well see that's exactly why I am confused.
> I understand the data integrity thing and the security thing, but
> how far do you take that?
>
> /users/1/projects/2/tasks/3/notes/4
>
> @user.find(params[:user_id]
> @project @user.projects.find(par
> Are there examples of projects that use this nesting stuff in the wild that
> we could actually see the code to? I'd love to figure out what I'm missing
> here, as I really feel like I'm not "getting" it. In the past, for security
> purposes, I'd just have the user *own* everything by user_id a
Well see that's exactly why I am confused.
I understand the data integrity thing and the security thing, but how far do
you take that?
/users/1/projects/2/tasks/3/notes/4
@user.find(params[:user_id]
@project @user.projects.find(params[:project_id]
@task = @project.tasks.find(params[:task_id]
@no
Some people use the concept of resource nesting or "belongs to" to
manage security, but it is pretty one-dimensional. More robust
security systems (role-based access control, for example) have a much
richer concept of authorization than could possibly be expressed in a
request string. I love nes
On Aug 3, 11:04 am, Brian Hogan <[EMAIL PROTECTED]> wrote:
> Forgive me for reopening an old thread, but
>
> > posts/1/comments/34
>
> > Which then lets me do
>
> > @post = user.posts.find(params[:post_id])
> > @comment = @post.comments.find(params[:id])
>
> Forgive me, but I actually do think t
Forgive me for reopening an old thread, but
> posts/1/comments/34
>
> Which then lets me do
>
> @post = user.posts.find(params[:post_id])
> @comment = @post.comments.find(params[:id])
Forgive me, but I actually do think that's silly. If I really needed
to do that I'd do
@comment = Comment.find
On 7/7/07, Josh Peek <[EMAIL PROTECTED]> wrote:
>
> I've seen a ton of tickets of people trying to extend
> polymorphic_path([...]) to do
> everything for them when a proper work around with named routes will
> do.
You are assuming that you know what the route will be. When developing a
control
Decided to take some action with a Rails ticket.
http://dev.rubyonrails.org/ticket/8932
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rubyonrails-
On Jul 8, 9:05 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote:
> > Agree. some_model/1/other_model/2 is a lame way to refer to join_model/1.
>
> Putting polymorphism aside, what about:
>
> posts/1/comments/34
>
> Which then lets me do
>
> @post = user.posts.find(params[:post_id])
> @comment = @
1) the uri
/albums/79/tracks/219
doesn't reveal whether the underlying association between Album and
Track is has-many, has-and-belongs-to-many, or has-and-belongs-to-many-
through. I see this as an asset -- you can refactor your model
associations as business requirements change without having
On 7/8/07, Josh Peek <[EMAIL PROTECTED]> wrote:
>
>
>
>
> On Jul 7, 1:22 pm, "Daniel N" <[EMAIL PROTECTED]> wrote:
> > I can't pastie it unfortunately but it. But I believe it goes for any
> time
> > you use a has_many :through relationship with additional data in the
> join
> > table. Without bo
On 7/8/07, Michael Koziarski <[EMAIL PROTECTED]> wrote:
>
> > Agree. some_model/1/other_model/2 is a lame way to refer to join_model/1.
>
> Putting polymorphism aside, what about:
>
> posts/1/comments/34
>
> Which then lets me do
>
> @post = user.posts.find(params[:post_id])
> @comment = @post.com
> Agree. some_model/1/other_model/2 is a lame way to refer to join_model/1.
Putting polymorphism aside, what about:
posts/1/comments/34
Which then lets me do
@post = user.posts.find(params[:post_id])
@comment = @post.comments.find(params[:id])
Does that suck?
--
Cheers
Koz
--~--~
Agree. some_model/1/other_model/2 is a lame way to refer to join_model/1.
Evan
On 7/7/07, Josh Peek <[EMAIL PROTECTED]> wrote:
>
> On Jul 7, 11:12 am, Geoff B <[EMAIL PROTECTED]> wrote:
> > I think a case can be made for using an [EMAIL PROTECTED], @track] nested
> > route
> > -- say a user bro
Josh,
I grok what Daniel is trying to say, but I can't tell if you do or
not. Perhaps this will help.
/mother/273753/child/234
/father/342986/child/234
/child/234
In all of those URLs it is very clear which single resource we are
referencing: Child 234. But the URLs give very different context
Josh Writes:
>"/companies/1/people/1" == BAD
>"/people/1" == GOOD
>
>I have no problem with nested collections.
>
>"/companies/1/people"
>
>You shouldn't need to be scoping person #1 if its the unique id.
But isn't that the rub? Who says the ids must be unique? True, Rails
support for composit
On Jul 7, 1:22 pm, "Daniel N" <[EMAIL PROTECTED]> wrote:
> I can't pastie it unfortunately but it. But I believe it goes for any time
> you use a has_many :through relationship with additional data in the join
> table. Without both sides of the join, you can't identify join, and
> therefore d
Those look like legitimate bugs in implementation, rather than caused
by confusion. I don't really see a point in extracting that
functionality in a plugin, with hope of making a come back to core. If
it's gets converted into a plugin, it should stay there, always.
Also, converting an edge functi
On 7/8/07, Josh Peek <[EMAIL PROTECTED]> wrote:
>
>
> On Jul 7, 1:40 am, "Daniel N" <[EMAIL PROTECTED]> wrote:
> > This makes it important to have both pieces of information. This is I
> > believe the same for any has_many :through association where you have
> > additional information in the join
I'm working on a project now, where we have things like:
/album/1/tracks
/tracks #=> not valid
/tracks/1 #=> valid
/tracks/1/artists#=> Assume a track has many artists
/artists/1/tracks#=> reverse of above; all the tracks for an
artist.
Basically, we want `/f
On Jul 7, 11:41 am, Pratik <[EMAIL PROTECTED]> wrote:
> Can you please point out to tickets related to the issue ? They'd
> surely provide a better insight to your point.
Heres a few: [7152], #8725, #8782, #8719, #8720, #8705, #8830, #8654,
#8640
--~--~-~--~~~---~--
Can you please point out to tickets related to the issue ? They'd
surely provide a better insight to your point.
Thanks,
Pratik
On 7/7/07, Josh Peek <[EMAIL PROTECTED]> wrote:
>
> On Jul 7, 11:24 am, "Gabe da Silveira" <[EMAIL PROTECTED]> wrote:
> > It sounds like the real issue is that there ar
On Jul 7, 11:24 am, "Gabe da Silveira" <[EMAIL PROTECTED]> wrote:
> It sounds like the real issue is that there are too many patches and
> too many bugs to manage. Well if it can't be implemented cleanly then
> maybe it should be pulled.
Another point I was trying to make. If it was pulling into
I gotta agree here. Presuming that people should always use
root-level routes is going too far. The URL carries a lot of
information, and why shouldn't the developer have access to it? Plus
I don't really see how this polymorphic routing magic has much effect
on people's design decisions. I do
On Jul 7, 11:12 am, Geoff B <[EMAIL PROTECTED]> wrote:
Since you are so passionate about nested polymorphic resource, it
seems like a perfect fit for you to make and maintain a plugin for
this.
--~--~-~--~~~---~--~~
You received this message because you are subsc
On Jul 7, 11:12 am, Geoff B <[EMAIL PROTECTED]> wrote:
> I think a case can be made for using an [EMAIL PROTECTED], @track] nested
> route
> -- say a user browsed to album 45, and then clicked track 219 -- if
> your UI requires a "back to album 45" navigational link on the track
> page, you could
I think a case can be made for using an [EMAIL PROTECTED], @track] nested route
-- say a user browsed to album 45, and then clicked track 219 -- if
your UI requires a "back to album 45" navigational link on the track
page, you couldn't infer the referring album id from the resource id
alone if the
On Jul 7, 10:59 am, Geoff B <[EMAIL PROTECTED]> wrote:
> So, are you saying that, instead of doing this:
>
> link_to @track.name, [EMAIL PROTECTED], @track]
>
> ...we should be required to do this:
>
> link_to @track.name, album_track_path(@album, @track)
I'm saying you should be doing ...
link
So, are you saying that, instead of doing this:
link_to @track.name, [EMAIL PROTECTED], @track]
...we should be required to do this:
link_to @track.name, album_track_path(@album, @track)
?
On Jul 7, 10:50 am, Josh Peek <[EMAIL PROTECTED]> wrote:
> On Jul 7, 10:08 am, DHH <[EMAIL PROTECTED]> w
On Jul 7, 10:08 am, DHH <[EMAIL PROTECTED]> wrote:
> I think it's perfectly fine to encourage people to not nest when they
> don't really care one way or another. But to outright "forbid" it is
> pushing it.
I wasn't clear about banning what..
I wanted to remove the whole polymorphic nesting wi
On 7/7/07, DHH <[EMAIL PROTECTED]> wrote:
>
>
> > You shouldn't need to be scoping person #1 if its the unique id.
>
> I think this is going too far. I too prefer to limit the scope to one
> level, but there are legitimate reasons to have deeper nesting. /
> albums/45/tracks/1 (where the track numb
> > I tend to agree with this. I don't really understand the need to
> > "canonically" identify a resource based on its context.
>
> > Other thoughts?
>
> The simple reason would be that you want your URLs to look that way.
I think this is also a reasonable argument. Again, I'm actually in the
ca
> "/companies/1/people/1" == BAD
> "/people/1" == GOOD
>
> You shouldn't need to be scoping person #1 if its the unique id.
>
> Its not in the spirit of Rails to be providing tools to help you
> practice bad habits.
I think this is going too far. I too prefer to limit the scope to one
level, but
On Jul 7, 1:40 am, "Daniel N" <[EMAIL PROTECTED]> wrote:
> This makes it important to have both pieces of information. This is I
> believe the same for any has_many :through association where you have
> additional information in the join model. Without both pieces of
> information you can't iden
On Jul 7, 2007, at 8:14 AM, Evan Weaver wrote:
>
> I tend to agree with this. I don't really understand the need to
> "canonically" identify a resource based on its context.
>
> Other thoughts?
>
> Evan
The simple reason would be that you want your URLs to look that way.
Joshua
--~--~
On 7/7/07, Evan Weaver <[EMAIL PROTECTED]> wrote:
>
>
> I tend to agree with this. I don't really understand the need to
> "canonically" identify a resource based on its context.
>
> Other thoughts?
>
> Evan
>
>
> > On 7/7/07, Josh Peek <[EMAIL PROTECTED]> wrote:
> > >
> > > I have a real grudge ag
I tend to agree with this. I don't really understand the need to
"canonically" identify a resource based on its context.
Other thoughts?
Evan
> On 7/7/07, Josh Peek <[EMAIL PROTECTED]> wrote:
> >
> > I have a real grudge against the new nested polymorphic path magic
> > stuff. I feel it encour
46 matches
Mail list logo
