Oh, and one other thought. If you are still concerned about the id in the url, in UserController#Index you could also check if the user is an admin, and if not then set params[:user_id] = current_user and then render :action => show instead of the index action. I haven't tried it in a while, but as I remember this would give non-admins a url that looks like index (e.g. http://example.com/users) but would be doing the the show action (e.g. same as http://example.com/users/####). You wouldn't have to play with the routing at all.
This is only a partial solution, because while it would work with the show action, the all of the other actions would still require the id in the url (i.e. http://example.com/users/####/edit). There might be something you could do in a routing block to hide it, or maybe something like inserting the id through rack, but I think all of those are going to be a lot of work and not much bang for the buck. On Jun 2, 9:51 pm, Fearless Fool <li...@ruby-forum.com> wrote: > @Dee: > > Yes, you're answering the right question. My addition of the .html > suffixes (suffixen?) was a brain bubble and should be ignored. > > I wonder if exposing the user id in the url is useful or prudent. I > agree with most RESTful philosophy, but even if authorization code is in > place to prevent the user 123 from accessing the account of user 142, > exposing the db-level user ID in the URL doesn't feel right. > > That's why I was asking about having two styles of routing: one where > the user ID is implicit (derived from session and authentication > credentials) for ordinary users, and one where the user ID is manifest > in the URL (for the administrator). > > But: CanCan looks like a sensible adjunct to Authlogic (even though I've > already written a Role model). I'll just go with the flow and use that > as it was intended. > > Thanks for the pointer. > > - ff > -- > Posted viahttp://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.