You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Kiran Ayyagari (JIRA)" <ji...@apache.org> on 2018/11/17 14:32:00 UTC

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

    [ 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.

> 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)