ResourceHandler errors about scim HOT 4 CLOSED

Well, current handlers won't work, but the change should be minimum, just change the return value to error.

from scim.

How would the server handle these custom errors? Should they be logged? Should they be returned to the client? Which status code should they produce (given that the custom error does not implement the StatusCoder interface)? I like the strictness of the current implementation, as it forces the user to return errors as specified by the SCIM RFC.

from scim.

A ScimError would be returned to the client in the same way scimError is, with the status code selected by the user. The errors already available, will still be available, and will be transformed into ScimErrors, as they currently are. And a user will be also to return 'constant errors', for example, the private one scimErrorUniqueness, ... The logging of errors would be managed by a middleware on top of the server, and the scim package should not worry about it.

On custom errors, for example, if the handler returns something like fmt.Errorf("my error"), I'll probably be transformed to ScimError{Detail: "my error", Status: 500}, If you return an error that implements StatusCoder then ScimError{Detail: err.Error(), Status: err.StatusCode()}

The requirement of extra errors is because there are many kinds of errors that can't be managed with the current ones available, especially when there are different systems involved. For example, typical HTTP authorizations errors, conflicts, bad requests on extra validations on custom extensions, validations that cannot be performed just in the schema, especially when you're trying to support different tenants, different IdPs each one of them with its own SCIM implementation with its own problems. The section https://tools.ietf.org/html/rfc7644#section-3.12 shows many cases that are currently not possible to return an appropriate error. It's also important to show in the details what was wrong for debugging purposes.

To point to a specific example, the errors possible in the GetAll method are currently only 501 or 500, for example, if a filter is used and the user does not exist, it's not possible to return a 404, and there are probably more examples like that.

I really believe it will improve the usability of the package.

from scim.

I understand that there are still some errors missing from the errors package, and I have no problem at all with defining more constants for each of the status codes specified by the RFC. I also like the idea of mapping errors that do not correspond with an existing constant to a 500 with the errors message. However, I do not like the idea of the StatusCoder interface because it might cause the server to break the RFC compliance by returning an unlisted status code.

In general, I would like to maintain the guarantee that the server will not return a non-compliant error code. Maybe we could add a NewInternalServerGetError(detail string) function for each HTTP method to allow a custom detail message?

from scim.