If you want to sacrifice some security for performance, you can skip the 
authenticity token verification:

You can add this to the controller which contains the action at hand:

protect_from_forgery :except => [:action_a, :action_b]

--Dan


tommy wrote:
> Thanks Rob, my reasoning was this:
> Page caching is the fastest solution because it allows nginx to serve
> the page without even touching Mongrel/Rails at all.
>
> This allows the page to load instantly for the user.
>
> If under load, it may take a second for the ajaxed login form to
> appear, but at least the user sees something instantly.
> -
> Fragment caching will still hit the Rails framework for the entire
> page request.
>
>
> More thoughts?
>
>
> On Sep 4, 9:38 am, "Rob Kaufman" <[EMAIL PROTECTED]> wrote:
>   
>> If you want to keep the token (which is a good thing) you can either:
>>
>> 1. remove the form from your template and have it be its own (non cache)
>> page.  This isn't the best UI choice but might be a good practical
>> solution.  Just don't let my wife (a usability engineer) know I told you ;-)
>>
>> 2. use fragment caching to cache the rest of the page and leave the form
>> dynamic.
>>
>> Both of your solutions mean just as many calls to the server which basically
>> is defeating your caching.  If you save a server call, but then have to
>> spend one you have almost as much overhead as you started with.  You might
>> gain some speed if the rest of the page is resource expensive to put
>> together, if its not that you've saved nothing.
>>
>> There may be other options, but thats what I've got off the top of my head
>>
>> Rob
>>
>> On Thu, Sep 4, 2008 at 9:01 AM, tommy <[EMAIL PROTECTED]> wrote:
>>
>>     
>>> I want to be able to use page caching but i have a login form that is
>>> using an authenticity token.
>>>       
>>> Any suggestions on approaching this?
>>>       
>>> some thoughts i had:
>>> 1. have a JS call to render the partial upon page load.
>>> 2. hmm, iframe the login form?
>>>       
>>     
> >
>   


--~--~---------~--~----~------------~-------~--~----~
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
-~----------~----~----~----~------~----~------~--~---

Reply via email to