every non-logged-in visitor to a radiant site gets infected with a _sitename_session cookie for no apparent reason. i had a look at this and think rails is to blame but is there anything radiant can do to suppress these useless and annoying cookies?
We used to use session :off in the SiteController, but that has been deprecated. I believe the answer is to remove SiteController and create a Rack middleware to serve pages.
We modified login_from_session in login_system.rb to check for the session cookie before accessing the session object. This prevents the session from being created.
Please send a patch and specs!
i solved it for now by changing User.find(session['user_id']) rescue nil to User.find(session['user_id']) rescue nil if cookies.size > 0. unfortunately i can't get the specs to run without a few hundred errors currently so can't really offer a spec.
User.find(session['user_id']) rescue nil
User.find(session['user_id']) rescue nil if cookies.size > 0
i changed to using User.find(session['user_id']) rescue nil unless cookies.empty? (same effect just looks nicer i think) which has the effect of not creating cookies while you browse a site but it does bust some specs. the specs that are failing don't seem to make any sense since the behaviors their testing work in a running app. the second, third and fifth failures in particular look odd ...expected to redirect to /login_required... is that even a path radiant uses?
User.find(session['user_id']) rescue nil unless cookies.empty?
i'll have a look at the other four failures later. in the meantime does anyone know what is up with the /login_required stuff?
failing specs: http://gist.github.com/400668
We do a lot of things in ApplicationController that should probably be done in something like an RadiantAdminController. There's no reason to force controllers to skip filters when they shouldn't be there in the first place.
This would break almost every extension, but I propose that we change our controllers that need authentication to inherit from RadiantAdminController so that SiteController won't ever touch the session (because it won't inherit all the authentication stuff). If we do that, it'll simplify the management of controllers.
Not only that, but if Radiant is to become an engine in Rails 3, then we can't predict what will happen in ApplicationController in the main app. I haven't looked into that yet, but my assumption is that a main application including Radiant will have it's own ApplicationController that conflicts with ours.
In the very least, having SiteController inherit from something that doesn't include authentication will prevent this problem.
I'm on board with this. Go for it.
This would help with caching too, since Rack::Cache normally passes through if there are any cookies at all. Is it too radical a shift for v1?
This would break every extension controller that inherits from ApplicationController. The move to 1.0 would be painful unless we ensured that all extensions are altered
I would argue that 1.0 is THE time to break things. ;) *goes back to his hole*
Jim and I have talked a little about this, but in general I think we are in agreement that we are striving to make 1.0 work well with existing extensions, while 2.0 -- based on Rails 3 -- will introduce a lot of breaking changes (by necessity).
In spirit I'm with you though. :)
If there is overwhelming support for this in 1.0, then I'm fine with it.
The 2 questions most often asked about radiant are:
The first is solved with 2.0 and rails 3 (and I want to get to that right away after 1.0). By making this change now, we'd make the experience that leads to question 2 even worse; that pushes people away from radiant (regardless of the reasons behind the difficulty).
There's a lot of inheritance from the resource controller these days, but I think you're right: it makes more sense to refactor the controllers and the login system together, and v1 should be an easy upgrade.
Prevent stty errors on JRuby while running bootstrap. [#57 state:hold]