glassfish
  1. glassfish
  2. GLASSFISH-19030

Creating or deleting custom resources using the Glassfish REST interface fails if secure-admin is enabled

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 3.1.2.2
    • Fix Version/s: None
    • Component/s: rest-interface
    • Labels:
      None

      Description

      We started to use the REST API with Glassfish 3.1.2 / 3.1.2.2 in order to create custom resources.
      Previously, we used AMX but this is now deprecated.

      Querying, creating or deleting custom resources with the REST interface worked fine as long the local development Glassfish
      was used without secure-admin enabled.

      But as soon as we enabled secure-admin using

      asadmin enable-secure-admin
      

      we could only query the custom resources, but neither create nor delete them.
      All attempts were rejected with HTTP 400 Bad Request.

        Activity

        Hide
        Jason Lee added a comment -

        The GlassFish REST interfaces are protected against CSRF attacks, which requires that a certain header (X-Requested-By) be set on all requests which change state (e.g., POST and DELETE). This is discussed and demonstrated in the "Using REST Interfaces to Administer GlassFish Server" of the GlassFish documentation: http://docs.oracle.com/cd/E26576_01/doc.312/e24928/general-administration.htm#GSADG00534

        Show
        Jason Lee added a comment - The GlassFish REST interfaces are protected against CSRF attacks, which requires that a certain header (X-Requested-By) be set on all requests which change state (e.g., POST and DELETE). This is discussed and demonstrated in the "Using REST Interfaces to Administer GlassFish Server" of the GlassFish documentation: http://docs.oracle.com/cd/E26576_01/doc.312/e24928/general-administration.htm#GSADG00534
        Hide
        jthoennes added a comment -

        In reply to comment #1:
        > The GlassFish REST interfaces are protected against CSRF attacks, which requires
        > that a certain header (X-Requested-By) be set on all requests which change state
        > (e.g., POST and DELETE). This is discussed and demonstrated in the "Using REST
        > Interfaces to Administer GlassFish Server" of the GlassFish documentation:
        > http://docs.oracle.com/cd/E26576_01/doc.312/e24928/general-administration.htm#GSADG00534

        Thanks, Lee. This answer was a bit surprising to us since we could not understand why such a simple header with a fixed value could help. But here we found more details:

        I would appreciate if you could update your docs to add this code snippet:

        ...
        import com.sun.jersey.api.client.filter.CsrfProtectionFilter;
        ...
            private static final String GLASSFISH_REST_X_REQUESTED_BY = "GlassFish REST HTML interface";
        ...
                webResource = client.resource( baseURI );
                // Added the Jersey and Cross-Site Request Forgery (CSRF) Filter because the REST requests that add, update, or
                // delete objects must specify the X-Requested-By header with the value "GlassFish REST HTML interface".
                webResource.addFilter( new CsrfProtectionFilter( GLASSFISH_REST_X_REQUESTED_BY ) );
        ...
        

        This is the most elegant way instead of adding the header manually to every request. It is also suggest in the above blog entry
        to stay up-to-date since the server side and client side filter will receive any further improvements at the same time.

        Anyway, thanks for the fast response and cheers, Jörg

        Show
        jthoennes added a comment - In reply to comment #1: > The GlassFish REST interfaces are protected against CSRF attacks, which requires > that a certain header (X-Requested-By) be set on all requests which change state > (e.g., POST and DELETE). This is discussed and demonstrated in the "Using REST > Interfaces to Administer GlassFish Server" of the GlassFish documentation: > http://docs.oracle.com/cd/E26576_01/doc.312/e24928/general-administration.htm#GSADG00534 Thanks, Lee. This answer was a bit surprising to us since we could not understand why such a simple header with a fixed value could help. But here we found more details: http://blog.alutam.com/2011/09/14/jersey-and-cross-site-request-forgery-csrf/ I would appreciate if you could update your docs to add this code snippet: ... import com.sun.jersey.api.client.filter.CsrfProtectionFilter; ... private static final String GLASSFISH_REST_X_REQUESTED_BY = "GlassFish REST HTML interface " ; ... webResource = client.resource( baseURI ); // Added the Jersey and Cross-Site Request Forgery (CSRF) Filter because the REST requests that add, update, or // delete objects must specify the X-Requested-By header with the value "GlassFish REST HTML interface " . webResource.addFilter( new CsrfProtectionFilter( GLASSFISH_REST_X_REQUESTED_BY ) ); ... This is the most elegant way instead of adding the header manually to every request. It is also suggest in the above blog entry to stay up-to-date since the server side and client side filter will receive any further improvements at the same time. Anyway, thanks for the fast response and cheers, Jörg
        Hide
        Jason Lee added a comment -

        All of the code there in the official docs is using curl for simplicity's sake, I'm guessing. Our docs team owns that, but my guess is that they wanted to present the simplest example possible without muddying the waters by using a library that hides some of the details. You are, correct, though, that if you're using Jersey, adding the filter is the correct approach.

        I'm not sure if the docs team would want to include Jersey Client-specific code in the official documentation, but I'll point out your request to them. Since Jersey/JAX-RS 2, which GlassFish 4 will ship, will include a standard client API, it might be appropriate, but that will be the docs team decision to make.

        At any rate, I'm glad you got it working. I have some unofficial discussions of the REST API on my blog (http://blogs.steeplesoft.com/tag/rest/) that might help, one of which discusses the CSRF protection.

        Show
        Jason Lee added a comment - All of the code there in the official docs is using curl for simplicity's sake, I'm guessing. Our docs team owns that, but my guess is that they wanted to present the simplest example possible without muddying the waters by using a library that hides some of the details. You are, correct, though, that if you're using Jersey, adding the filter is the correct approach. I'm not sure if the docs team would want to include Jersey Client-specific code in the official documentation, but I'll point out your request to them. Since Jersey/JAX-RS 2, which GlassFish 4 will ship, will include a standard client API, it might be appropriate, but that will be the docs team decision to make. At any rate, I'm glad you got it working. I have some unofficial discussions of the REST API on my blog ( http://blogs.steeplesoft.com/tag/rest/ ) that might help, one of which discusses the CSRF protection.
        Hide
        jthoennes added a comment -

        Thanks for the kind response and the pointer to your blog.

        If Jersey is part of the official GF API, it would be good to tell about the client filter.
        Anyway, it is working now

        Show
        jthoennes added a comment - Thanks for the kind response and the pointer to your blog. If Jersey is part of the official GF API, it would be good to tell about the client filter. Anyway, it is working now

          People

          • Assignee:
            Jason Lee
            Reporter:
            jthoennes
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: