What's the best place to keep the user_id from the request, so it can be referenced from the scope's lambda method? Rather than store it in MGR.user_id, is there a safer place to store it? (or is there a way to access the request object outside of the controller?)
On Sunday, July 29, 2012 2:26:30 PM UTC-4, Frederick Cheung wrote: > > On Sunday, July 29, 2012 6:54:50 PM UTC+1, tom_302 wrote: > > Thanks - and good call on the lambda for delaying evaluation of the > user_id. > > > > > > Unfortunately, I also need the user_id to authenticate with the legacy > application in order to load its codebase; I'm defining my ActiveRecord > models dynamically from this codebase. > > > > > > I've been able to use AR scopes to hide all of the > checkin/checkout/version control. And I can pull the http authentication > off any request. I just wish the controller could evaluate my > :before_filter before it evaluates its AR models. > > > > > > I'm looking into alternatives, but I'd have to give up the dynamic model > definition and loose some flexibility there. > > > > I really think that anything that depends on class load order is fatally > flawed (and as I said before, in production mode rails will load your app > classes before the first request arrives. > > > > > Regarding storing the user_id in a constant, i thought rails doesn't > share any information between requests; Isn't it up to the server to keep > variable states separate however it loads/shares instances of the rails > application? Please explain. > > > > > Rails doesn't enforce anything like this. Controller instances only last > the length of the corresponding request, so anything set there 'disappears' > but (except in development mode) classes aren't reloaded between requests : > class variables, constants etc. are shared across requests, and will > obviously trigger weird behaviour if you run rails in threadsafe modd > > Fred > > > > > On Saturday, July 28, 2012 11:06:27 AM UTC-4, Frederick Cheung wrote: > > > > On Saturday, July 28, 2012 4:20:36 AM UTC+1, tom_302 wrote: > > > > > > > > > > NativeException ([from a java method of the legacy application]): > > > > config/initializers/myapp.rb:169:in `current_user' > > > > config/initializers/myapp.rb:351:in `define_model_scope' > > > > config/initializers/myapp.rb:625:in `acts_as_controlled' > > > > app/models/document.rb:2:in `Document' > > > > app/models/document.rb:1:in `(root)' > > > > app/models/document.rb:456:in `load_file' > > > > app/controllers/documents_controller.rb:1:in `(root)' > > > > app/controllers/documents_controller.rb:456:in `load_file' > > > > > > > > > > Rendered > vendor/bundle/jruby/1.8/bundler/gems/rails-80f6547f5b25/actionpack/lib/action_dispatch/middleware/templates/rescues/_trace.erb > > (27.0ms) > > > > Rendered > vendor/bundle/jruby/1.8/bundler/gems/rails-80f6547f5b25/actionpack/lib/action_dispatch/middleware/templates/rescues/_request_and_response.erb > > (3.0ms) > > > > Rendered > vendor/bundle/jruby/1.8/bundler/gems/rails-80f6547f5b25/actionpack/lib/action_dispatch/middleware/templates/rescues/diagnostics.erb > > within rescues/layout (46.0ms) > > > > > > > > > > One solution would be to short-circuit acts_as_controlled if MGR.user > isn't set, store a reference to the model, and finally execute > acts_as_controlled on all referenced models at the end of the > :before_filter method, but that approach would mean evaluating each model > twice. > > > > > > > > > > Is there a better way to make ApplicationController :before_filter > execute before the Document model is evaluated by DocumentController? > > > > > > > > > > > > > > This sounds horribly brittle (and in production mode the whole > application is loaded at boot time, so I think you'll have problems too). I > think you'd be better off rethinking how your acts_as_controlled method > works > > > > > > (for example generate the scopes using lambda so that they can change > their conditions at runtime) > > > > > > > > > > > > PS: Also, is it even safe to store the user id in a constant like MGR? > I haven't seen any warnings about it being redefined so far, but I'm not > quite sure how rails instances are managed across requests & sessions with > JRuby and Tomcat. > > > > > > That depends entirely on what MGR.user= does. That could be implemented > in a threadsafe way (eg using Thread.current) or in a thread dangerous way > > > > > > Fred > > -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/nGb2d39nwaAJ. For more options, visit https://groups.google.com/groups/opt_out.
