Changing some GETs to POSTs

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Changing some GETs to POSTs

Dean Yu
Changing some GETs to POSTs

I've noticed that deleting builds and views, and renaming jobs use form submissions using GET. I'd like to change these to use POST to pick up the XSRF crumb protection when that feature is enabled, and add a requirePOST() check to the corresponding Java methods. This might break people who are relying on being able to just send a request to these URLs to perform these actions. I could conditionalize the requirePOST check to only happen if the XSRF protection is on, but I think that a POST is generally more "correct" in these situations regardless.

How do other people feel about this change?

  -- Dean


Reply | Threaded
Open this post in threaded view
|

Re: Changing some GETs to POSTs

Kohsuke Kawaguchi
Administrator

+1.

Dean Yu wrote:

> I've noticed that deleting builds and views, and renaming jobs use form
> submissions using GET. I'd like to change these to use POST to pick up
> the XSRF crumb protection when that feature is enabled, and add a
> requirePOST() check to the corresponding Java methods. This might break
> people who are relying on being able to just send a request to these
> URLs to perform these actions. I could conditionalize the requirePOST
> check to only happen if the XSRF protection is on, but I think that a
> POST is generally more "correct" in these situations regardless.
>
> How do other people feel about this change?
>
>   -- Dean
>
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing some GETs to POSTs

Jorg Heymans-4
In reply to this post by Dean Yu
On Thu, Jul 9, 2009 at 1:22 AM, Dean Yu<[hidden email]> wrote:

> I've noticed that deleting builds and views, and renaming jobs use form
> submissions using GET. I'd like to change these to use POST to pick up the
> XSRF crumb protection when that feature is enabled, and add a requirePOST()
> check to the corresponding Java methods. This might break people who are
> relying on being able to just send a request to these URLs to perform these
> actions. I could conditionalize the requirePOST check to only happen if the
> XSRF protection is on, but I think that a POST is generally more "correct"
> in these situations regardless.
>
> How do other people feel about this change?

+1, as long as i can keep pressing the back button without annoying
browser popups about duplicate form submissions.

Jorg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Changing some GETs to POSTs

Dean Yu
Re: Changing some GETs to POSTs I don’t see how that can be avoided. How do you avoid those popups when you back through submitting a project configuration form?

  -- Dean


On 7/8/09 11:20 PM, "Jorg Heymans" <jorg.heymans@...> wrote:

On Thu, Jul 9, 2009 at 1:22 AM, Dean Yu<dty@...> wrote:
> I've noticed that deleting builds and views, and renaming jobs use form
> submissions using GET. I'd like to change these to use POST to pick up the
> XSRF crumb protection when that feature is enabled, and add a requirePOST()
> check to the corresponding Java methods. This might break people who are
> relying on being able to just send a request to these URLs to perform these
> actions. I could conditionalize the requirePOST check to only happen if the
> XSRF protection is on, but I think that a POST is generally more "correct"
> in these situations regardless.
>
> How do other people feel about this change?

+1, as long as i can keep pressing the back button without annoying
browser popups about duplicate form submissions.

Jorg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Reply | Threaded
Open this post in threaded view
|

Re: Changing some GETs to POSTs

sumit shah-2
Do a redirect to a GET after the POST, see:

http://balusc.blogspot.com/2007/03/post-redirect-get-pattern.html

Its also how django apps etc do it as well.

On Jul 8, 2009, at 11:27 PM, Dean Yu wrote:

> I don’t see how that can be avoided. How do you avoid those popups  
> when you back through submitting a project configuration form?
>
>   -- Dean
>
>
> On 7/8/09 11:20 PM, "Jorg Heymans" <[hidden email]> wrote:
>
>> On Thu, Jul 9, 2009 at 1:22 AM, Dean Yu<[hidden email]> wrote:
>> > I've noticed that deleting builds and views, and renaming jobs  
>> use form
>> > submissions using GET. I'd like to change these to use POST to  
>> pick up the
>> > XSRF crumb protection when that feature is enabled, and add a  
>> requirePOST()
>> > check to the corresponding Java methods. This might break people  
>> who are
>> > relying on being able to just send a request to these URLs to  
>> perform these
>> > actions. I could conditionalize the requirePOST check to only  
>> happen if the
>> > XSRF protection is on, but I think that a POST is generally more  
>> "correct"
>> > in these situations regardless.
>> >
>> > How do other people feel about this change?
>>
>> +1, as long as i can keep pressing the back button without annoying
>> browser popups about duplicate form submissions.
>>
>> Jorg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Changing some GETs to POSTs

Richard Bywater
In reply to this post by Dean Yu
Sounds good to me-  means that Hudson won't be breaking the golden
rule that GETs shouldn't alter data... (well I think it should be a
rule even if others don't :) )

Richard.

On Thu, Jul 9, 2009 at 11:22 AM, Dean Yu<[hidden email]> wrote:

> I've noticed that deleting builds and views, and renaming jobs use form
> submissions using GET. I'd like to change these to use POST to pick up the
> XSRF crumb protection when that feature is enabled, and add a requirePOST()
> check to the corresponding Java methods. This might break people who are
> relying on being able to just send a request to these URLs to perform these
> actions. I could conditionalize the requirePOST check to only happen if the
> XSRF protection is on, but I think that a POST is generally more "correct"
> in these situations regardless.
>
> How do other people feel about this change?
>
>   -- Dean
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Changing some GETs to POSTs

Kohsuke Kawaguchi
Administrator
In reply to this post by sumit shah-2

The ones in question, like deleting/renaming builds and jobs alerady do
redirects to GET after POST, so I consider this a non-issue.

sumit shah wrote:

> Do a redirect to a GET after the POST, see:
>
> http://balusc.blogspot.com/2007/03/post-redirect-get-pattern.html
>
> Its also how django apps etc do it as well.
>
> On Jul 8, 2009, at 11:27 PM, Dean Yu wrote:
>
>> I don�t see how that can be avoided. How do you avoid those popups  
>> when you back through submitting a project configuration form?
>>
>>   -- Dean
>>
>>
>> On 7/8/09 11:20 PM, "Jorg Heymans" <[hidden email]> wrote:
>>
>>> On Thu, Jul 9, 2009 at 1:22 AM, Dean Yu<[hidden email]> wrote:
>>> > I've noticed that deleting builds and views, and renaming jobs  
>>> use form
>>> > submissions using GET. I'd like to change these to use POST to  
>>> pick up the
>>> > XSRF crumb protection when that feature is enabled, and add a  
>>> requirePOST()
>>> > check to the corresponding Java methods. This might break people  
>>> who are
>>> > relying on being able to just send a request to these URLs to  
>>> perform these
>>> > actions. I could conditionalize the requirePOST check to only  
>>> happen if the
>>> > XSRF protection is on, but I think that a POST is generally more  
>>> "correct"
>>> > in these situations regardless.
>>> >
>>> > How do other people feel about this change?
>>>
>>> +1, as long as i can keep pressing the back button without annoying
>>> browser popups about duplicate form submissions.
>>>
>>> Jorg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/


smime.p7s (4K) Download Attachment