[jira] [Created] (FC-258) Updating the way FortResponse is served

Discussion:

Kiran Ayyagari (JIRA)

2018-11-16 15:09:00 UTC

Kiran Ayyagari created FC-258:
---------------------------------

Summary: Updating the way FortResponse is served
Key: FC-258
URL: https://issues.apache.org/jira/browse/FC-258
Project: FORTRESS
Issue Type: Bug
Reporter: Kiran Ayyagari

The FortResponse instance created as a result of operation exception is still sent to the client with a HTTP status code of "200 OK" forcing clients to rely on the {{errorCode}} field to figure out the actual status of the operation.

For example when the below request is sent to a stock Fortress REST service
{code}
curl -POST http://localhost:7070/fortress-rest/userAdd --header "Content-Type: application/json" --header "Accept: application/json" --header "Authorization: Basic dGVzdDpwYXNzd29yZA==" -v -d '{ "entity": { "fqcn": "org.apache.directory.fortress.core.model.User", "userId": "test1", "ou": "non-existing-ou" }, "contextId": "HOME" }'
{code}
the below success response is received though the request was failed due to a validation error which ideally should have been responded with a "400 bad request" error.
{code}
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 7070 (#0)

POST /fortress-rest/userAdd HTTP/1.1
Host: localhost:7070
User-Agent: curl/7.54.0
Content-Type: application/json
Accept: application/json
Authorization: Basic dGVzdDpwYXNzd29yZA==
Content-Length: 138

* upload completely sent off: 138 out of 138 bytes
< HTTP/1.1 200
< Date: Fri, 16 Nov 2018 15:05:04 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
{"errorCode":1035,"isAuthorized":null,"errorMessage":"validate detected invalid orgUnit name [non-existing-ou] adding user with userId [test1]","entity":null,"entities":null,"values":null,"valueSet":null,"session":null}
{code}

I propose to add a new {{httpStatusCode}} field to FortResponse class which can be set appropriately and modify/add the CXF interceptor to change the outgoing response's status accordingly.

--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Shawn McKinney (JIRA)

2018-11-16 19:09:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/FC-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689899#comment-16689899 ]

Shawn McKinney commented on FC-258:
-----------------------------------

Agreed. What HTTP other status codes need to be mapped from the fortress service layer in addition to 400, if any?

Post by Kiran Ayyagari (JIRA)
Updating the way FortResponse is served
---------------------------------------
Key: FC-258
URL: https://issues.apache.org/jira/browse/FC-258
Project: FORTRESS
Issue Type: Bug
Reporter: Kiran Ayyagari
Priority: Major
The FortResponse instance created as a result of operation exception is still sent to the client with a HTTP status code of "200 OK" forcing clients to rely on the {{errorCode}} field to figure out the actual status of the operation.
For example when the below request is sent to a stock Fortress REST service
{code}
curl -POST http://localhost:7070/fortress-rest/userAdd --header "Content-Type: application/json" --header "Accept: application/json" --header "Authorization: Basic dGVzdDpwYXNzd29yZA==" -v -d '{ "entity": { "fqcn": "org.apache.directory.fortress.core.model.User", "userId": "test1", "ou": "non-existing-ou" }, "contextId": "HOME" }'
{code}
the below success response is received though the request was failed due to a validation error which ideally should have been responded with a "400 bad request" error.
{code}
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 7070 (#0)

POST /fortress-rest/userAdd HTTP/1.1
Host: localhost:7070
User-Agent: curl/7.54.0
Content-Type: application/json
Accept: application/json
Authorization: Basic dGVzdDpwYXNzd29yZA==
Content-Length: 138

* upload completely sent off: 138 out of 138 bytes
< HTTP/1.1 200
< Date: Fri, 16 Nov 2018 15:05:04 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
{"errorCode":1035,"isAuthorized":null,"errorMessage":"validate detected invalid orgUnit name [non-existing-ou] adding user with userId [test1]","entity":null,"entities":null,"values":null,"valueSet":null,"session":null}
{code}
I propose to add a new {{httpStatusCode}} field to FortResponse class which can be set appropriately and modify/add the CXF interceptor to change the outgoing response's status accordingly.

--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Kiran Ayyagari (JIRA)

2018-11-17 14:26:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/FC-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690570#comment-16690570 ]

Kiran Ayyagari commented on FC-258:
-----------------------------------

So far mapped the below exceptions:
FinderException - 404
PasswordException - 400
ValidationException - 400

All other exceptions have status code 500 by default.

POST /fortress-rest/userAdd HTTP/1.1
Host: localhost:7070
User-Agent: curl/7.54.0
Content-Type: application/json
Accept: application/json
Authorization: Basic dGVzdDpwYXNzd29yZA==
Content-Length: 138

* upload completely sent off: 138 out of 138 bytes
< HTTP/1.1 200
< Date: Fri, 16 Nov 2018 15:05:04 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
{"errorCode":1035,"isAuthorized":null,"errorMessage":"validate detected invalid orgUnit name [non-existing-ou] adding user with userId [test1]","entity":null,"entities":null,"values":null,"valueSet":null,"session":null}
{code}
I propose to add a new {{httpStatusCode}} field to FortResponse class which can be set appropriately and modify/add the CXF interceptor to change the outgoing response's status accordingly.

--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Kiran Ayyagari (JIRA)

2018-11-17 14:32:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/FC-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690570#comment-16690570 ]

Kiran Ayyagari edited comment on FC-258 at 11/17/18 2:31 PM:
-------------------------------------------------------------

So far mapped the below exceptions:

||Exception Class||HTTP Status Code||
|AuthorizationException|403|
|FinderException|404|
|PasswordException|400|
|ValidationException|400|

All other exceptions have status code 500 by default.

was (Author: akiran):
So far mapped the below exceptions:
FinderException - 404
PasswordException - 400
ValidationException - 400

All other exceptions have status code 500 by default.

POST /fortress-rest/userAdd HTTP/1.1
Host: localhost:7070
User-Agent: curl/7.54.0
Content-Type: application/json
Accept: application/json
Authorization: Basic dGVzdDpwYXNzd29yZA==
Content-Length: 138

* upload completely sent off: 138 out of 138 bytes
< HTTP/1.1 200
< Date: Fri, 16 Nov 2018 15:05:04 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
{"errorCode":1035,"isAuthorized":null,"errorMessage":"validate detected invalid orgUnit name [non-existing-ou] adding user with userId [test1]","entity":null,"entities":null,"values":null,"valueSet":null,"session":null}
{code}
I propose to add a new {{httpStatusCode}} field to FortResponse class which can be set appropriately and modify/add the CXF interceptor to change the outgoing response's status accordingly.

--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Shawn McKinney (JIRA)

2018-11-19 21:26:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/FC-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16692299#comment-16692299 ]

Shawn McKinney commented on FC-258:
-----------------------------------

OK, just now testing these changes in the FC-247 branch of enmasse. When the fortress client goes through enmasse it's getting HTTP 500 errors on certain test cases.

Reason being when fortress itself using REST incorrectly and has to process these HTTP status codes. Here's where HTTP post occurs,

    public String post( String userId, String password, String szInput, String function ) throws RestException
    {
        LOG.debug( "post uri=[{}], function=[{}], request=[{}]", uri, function, szInput );
        String szResponse = null;
        HttpPost post = new HttpPost( uri + function);
        post.addHeader( "Accept", "text/xml" );
        setMethodHeaders( post );
        try
        {
            HttpEntity entity = new StringEntity( szInput, ContentType.TEXT_XML );
            post.setEntity( entity );
            org.apache.http.client.HttpClient httpclient = HttpClientBuilder.create().useSystemProperties()
                .setDefaultCredentialsProvider(getCredentialProvider(userId, password)).build();
            HttpResponse response = httpclient.execute( post );
            String error;

            switch ( response.getStatusLine().getStatusCode() )
            {
                case HTTP_OK :
                    szResponse = IOUtils.toString( response.getEntity().getContent(), "UTF-8" );
                    LOG.debug( "post uri=[{}], function=[{}], response=[{}]", uri, function, szResponse );
                    break;
                case HTTP_401_UNAUTHORIZED :
                    error = generateErrorMessage( uri, function, "401 function unauthorized on host" );
                    LOG.error( error );
                    throw new RestException( GlobalErrIds.REST_UNAUTHORIZED_ERR, error );
                case HTTP_403_FORBIDDEN :
                    error = generateErrorMessage( uri, function, "403 function forbidden on host" );
                    LOG.error( error );
                    throw new RestException( GlobalErrIds.REST_FORBIDDEN_ERR, error );
                case HTTP_404_NOT_FOUND :
                    error = generateErrorMessage( uri, function, "404 not found from host" );
                    LOG.error( error );
                    throw new RestException( GlobalErrIds.REST_NOT_FOUND_ERR, error );
                default :
                    error = generateErrorMessage( uri, function, "error received from host: " + response.getStatusLine().getStatusCode() );
                    LOG.error( error );
                    throw new RestException( GlobalErrIds.REST_UNKNOWN_ERR, error );
            }
        }

POST /fortress-rest/userAdd HTTP/1.1
Host: localhost:7070
User-Agent: curl/7.54.0
Content-Type: application/json
Accept: application/json
Authorization: Basic dGVzdDpwYXNzd29yZA==
Content-Length: 138

* upload completely sent off: 138 out of 138 bytes
< HTTP/1.1 200
< Date: Fri, 16 Nov 2018 15:05:04 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
{"errorCode":1035,"isAuthorized":null,"errorMessage":"validate detected invalid orgUnit name [non-existing-ou] adding user with userId [test1]","entity":null,"entities":null,"values":null,"valueSet":null,"session":null}
{code}
I propose to add a new {{httpStatusCode}} field to FortResponse class which can be set appropriately and modify/add the CXF interceptor to change the outgoing response's status accordingly.

--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Shawn McKinney (JIRA)

2018-11-19 22:08:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/FC-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16692344#comment-16692344 ]

Shawn McKinney commented on FC-258:
-----------------------------------

Was able to get the tests to run by doing this:

                case 500:
                case HTTP_VALIDATION_EXCEPTION:
                case HTTP_OK :
                    szResponse = IOUtils.toString( response.getEntity().getContent(), "UTF-8" );
                    LOG.debug( "post uri=[{}], function=[{}], response=[{}]", uri, function, szResponse );
                    break;

POST /fortress-rest/userAdd HTTP/1.1
Host: localhost:7070
User-Agent: curl/7.54.0
Content-Type: application/json
Accept: application/json
Authorization: Basic dGVzdDpwYXNzd29yZA==
Content-Length: 138

* upload completely sent off: 138 out of 138 bytes
< HTTP/1.1 200
< Date: Fri, 16 Nov 2018 15:05:04 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
{"errorCode":1035,"isAuthorized":null,"errorMessage":"validate detected invalid orgUnit name [non-existing-ou] adding user with userId [test1]","entity":null,"entities":null,"values":null,"valueSet":null,"session":null}
{code}
I propose to add a new {{httpStatusCode}} field to FortResponse class which can be set appropriately and modify/add the CXF interceptor to change the outgoing response's status accordingly.

--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Kiran Ayyagari (JIRA)

2018-11-20 16:48:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/FC-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kiran Ayyagari reassigned FC-258:
---------------------------------

Assignee: Kiran Ayyagari

Post by Kiran Ayyagari (JIRA)
Updating the way FortResponse is served
---------------------------------------
Key: FC-258
URL: https://issues.apache.org/jira/browse/FC-258
Project: FORTRESS
Issue Type: Bug
Reporter: Kiran Ayyagari
Assignee: Kiran Ayyagari
Priority: Major
The FortResponse instance created as a result of operation exception is still sent to the client with a HTTP status code of "200 OK" forcing clients to rely on the {{errorCode}} field to figure out the actual status of the operation.
For example when the below request is sent to a stock Fortress REST service
{code}
curl -POST http://localhost:7070/fortress-rest/userAdd --header "Content-Type: application/json" --header "Accept: application/json" --header "Authorization: Basic dGVzdDpwYXNzd29yZA==" -v -d '{ "entity": { "fqcn": "org.apache.directory.fortress.core.model.User", "userId": "test1", "ou": "non-existing-ou" }, "contextId": "HOME" }'
{code}
the below success response is received though the request was failed due to a validation error which ideally should have been responded with a "400 bad request" error.
{code}
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 7070 (#0)

POST /fortress-rest/userAdd HTTP/1.1
Host: localhost:7070
User-Agent: curl/7.54.0
Content-Type: application/json
Accept: application/json
Authorization: Basic dGVzdDpwYXNzd29yZA==
Content-Length: 138

* upload completely sent off: 138 out of 138 bytes
< HTTP/1.1 200
< Date: Fri, 16 Nov 2018 15:05:04 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
{"errorCode":1035,"isAuthorized":null,"errorMessage":"validate detected invalid orgUnit name [non-existing-ou] adding user with userId [test1]","entity":null,"entities":null,"values":null,"valueSet":null,"session":null}
{code}
I propose to add a new {{httpStatusCode}} field to FortResponse class which can be set appropriately and modify/add the CXF interceptor to change the outgoing response's status accordingly.

--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Shawn McKinney (JIRA)

2018-11-22 14:57:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/FC-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695974#comment-16695974 ]

Shawn McKinney commented on FC-258:
-----------------------------------

Here's what I ended up with.

                case HTTP_401_UNAUTHORIZED :
                    error = generateErrorMessage( uri, function, "401 function unauthorized on host" );
                    LOG.error( error );
                    throw new RestException( GlobalErrIds.REST_UNAUTHORIZED_ERR, error );
                case HTTP_403_FORBIDDEN :
                    error = generateErrorMessage( uri, function, "403 function forbidden on host" );
                    LOG.error( error );
                    throw new RestException( GlobalErrIds.REST_FORBIDDEN_ERR, error );
                case HTTP_404_NOT_FOUND:
                case HTTP_500_INTERNAL_SERVER_ERROR:
                case HTTP_400_VALIDATION_EXCEPTION:
                    szResponse = IOUtils.toString( response.getEntity().getContent(), "UTF-8" );
                    if( StringUtils.isNotEmpty( szResponse ) )
                    {
                        LOG.debug( "post uri=[{}], function=[{}], response=[{}]", uri, function, szResponse );
                    }
                    else
                    {
                        error = generateErrorMessage( uri, function, "HTTP Error:" + response.getStatusLine().getStatusCode());
                        LOG.error( error );
                        throw new RestException( GlobalErrIds.REST_NOT_FOUND_ERR, error );
                    }
                    break;

Post by Kiran Ayyagari (JIRA)
Updating the way FortResponse is served
---------------------------------------
Key: FC-258
URL: https://issues.apache.org/jira/browse/FC-258
Project: FORTRESS
Issue Type: Bug
Reporter: Kiran Ayyagari
Assignee: Kiran Ayyagari
Priority: Major
The FortResponse instance created as a result of operation exception is still sent to the client with a HTTP status code of "200 OK" forcing clients to rely on the {{errorCode}} field to figure out the actual status of the operation.
For example when the below request is sent to a stock Fortress REST service
{code}
curl -POST http://localhost:7070/fortress-rest/userAdd --header "Content-Type: application/json" --header "Accept: application/json" --header "Authorization: Basic dGVzdDpwYXNzd29yZA==" -v -d '{ "entity": { "fqcn": "org.apache.directory.fortress.core.model.User", "userId": "test1", "ou": "non-existing-ou" }, "contextId": "HOME" }'
{code}
the below success response is received though the request was failed due to a validation error which ideally should have been responded with a "400 bad request" error.
{code}
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 7070 (#0)

POST /fortress-rest/userAdd HTTP/1.1
Host: localhost:7070
User-Agent: curl/7.54.0
Content-Type: application/json
Accept: application/json
Authorization: Basic dGVzdDpwYXNzd29yZA==
Content-Length: 138

* upload completely sent off: 138 out of 138 bytes
< HTTP/1.1 200
< Date: Fri, 16 Nov 2018 15:05:04 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
{"errorCode":1035,"isAuthorized":null,"errorMessage":"validate detected invalid orgUnit name [non-existing-ou] adding user with userId [test1]","entity":null,"entities":null,"values":null,"valueSet":null,"session":null}
{code}
I propose to add a new {{httpStatusCode}} field to FortResponse class which can be set appropriately and modify/add the CXF interceptor to change the outgoing response's status accordingly.

--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Shawn McKinney (JIRA)

2018-11-22 14:59:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/FC-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695978#comment-16695978 ]

Shawn McKinney commented on FC-258:
-----------------------------------

Tested changes, we're good with these changes to core and enmasse.

Post by Kiran Ayyagari (JIRA)
Updating the way FortResponse is served
---------------------------------------
Key: FC-258
URL: https://issues.apache.org/jira/browse/FC-258
Project: FORTRESS
Issue Type: Bug
Reporter: Kiran Ayyagari
Assignee: Kiran Ayyagari
Priority: Major
The FortResponse instance created as a result of operation exception is still sent to the client with a HTTP status code of "200 OK" forcing clients to rely on the {{errorCode}} field to figure out the actual status of the operation.
For example when the below request is sent to a stock Fortress REST service
{code}
curl -POST http://localhost:7070/fortress-rest/userAdd --header "Content-Type: application/json" --header "Accept: application/json" --header "Authorization: Basic dGVzdDpwYXNzd29yZA==" -v -d '{ "entity": { "fqcn": "org.apache.directory.fortress.core.model.User", "userId": "test1", "ou": "non-existing-ou" }, "contextId": "HOME" }'
{code}
the below success response is received though the request was failed due to a validation error which ideally should have been responded with a "400 bad request" error.
{code}
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 7070 (#0)

POST /fortress-rest/userAdd HTTP/1.1
Host: localhost:7070
User-Agent: curl/7.54.0
Content-Type: application/json
Accept: application/json
Authorization: Basic dGVzdDpwYXNzd29yZA==
Content-Length: 138

* upload completely sent off: 138 out of 138 bytes
< HTTP/1.1 200
< Date: Fri, 16 Nov 2018 15:05:04 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
{"errorCode":1035,"isAuthorized":null,"errorMessage":"validate detected invalid orgUnit name [non-existing-ou] adding user with userId [test1]","entity":null,"entities":null,"values":null,"valueSet":null,"session":null}
{code}
I propose to add a new {{httpStatusCode}} field to FortResponse class which can be set appropriately and modify/add the CXF interceptor to change the outgoing response's status accordingly.

--
This message was sent by Atlassian JIRA
(v7.6.3#76005)