Hi Girish,
thanks for the explanation, however if i create a last statement in a
groovy service:
return error("this is the error message")
then i get an error 500 returned, however not showing the error message
of the service.
Regards,
Hans
On 10/2/20 12:14 AM, Girish Vasmatkar wrote:
Thanks Hans.
The error codes are broadly categorized in three types based on what
ofbiz is generating during service call -
1. 400 Bad Request = if ServiceValidationException is thrown. This
indicates client error and client must make amends to the request.
Example, service's required IN parameter were missing in the JSON body.
2. 422 Unprocessable Entity = if GenericEntityException is thrown.
This also indicates client error but also indicates that the request
was syntactically correct but semantically wrong. Example - while
creating a product, *productTypeId* was provided in the request, but
it didn't exist. This indicates client error again, but the json was
not malformed.
3. 404 NotFoundException = if service being invoked does not exist, or
is not declared export=true, or action attribute is not defined.
4. 500 Internal Server Error = Any other category of exception that
might be thrown from the service.
In all three cases, appropriate error messages from the original
exception should be included in the error response.
Best,
Girish
On Thu, Oct 1, 2020 at 1:43 PM Hans Bakker <[email protected]
<mailto:[email protected]>> wrote:
Hi Girish,
yes userLogin is working fine now,
further i see you are working on the error messages?
would be nice to get the ofbiz error message together with the
error code 500?
keep up the good work, it is getting better and better!
Regards,
Hans
On 10/1/20 10:49 AM, Girish Vasmatkar wrote:
Hi Hans,
This is now implemented/fixed with commit8545cfe
<https://github.com/apache/ofbiz-plugins/commit/8545cfebb2193bead7d06bd8e8cdb5108d24b209>
.
Best,
Girish
HotWax Systems
On Tue, Sep 29, 2020 at 5:26 PM Hans Bakker
<[email protected] <mailto:[email protected]>>
wrote:
Hi Girish, thanks for your prompt reply,
the login map need to be filled when the related token is
available, what is currently not the case.
Not sure if this is directly related to the Auth=false
parameter, you know that better,
Regards, Hans
On 9/29/20 4:20 PM, Girish Vasmatkar wrote:
Hi Hans
Since you specifically mentioned about groovy service, I
would think it is true for other services as well.
It would possibly be happening, if the service itself is
declared with auth=false, so no token check is happening and
hence userLogin is not retrieved from the token.
Can you confirm if this is the case? The userLogin is added
to the service call before delegating the service call to
dispatcher after jwt has been verified. But in case of
auth=false, services, auth is bypassed and hence userLogin
is not set.
I guess the key here is to bypass token validation if, and
only if, the Authorization header is absent, otherwise
perform validation. I had a discussion about this with
Jacopo as well and here is what can be done (applicable for
*/services *endpoint ) -
If auth=false and *Authorization* header is */present/*,
validate token and return error if invalid. Else set
userLogin in context and delegate the call to dispatcher.
If auth=false and *Authorization* header is *absent, *just
call the service. The service will be executed */without/*
userLogin in context.
I will try to work on this change in the next couple days.
Best,
Girish
HotWax Systems
Best,
Girish
HotWax Systems
On Tue, Sep 29, 2020 at 6:20 AM Hans Bakker
<[email protected]
<mailto:[email protected]>> wrote:
Hi Girish,
thanks for your last email, that is working now too....
however....another question,
If i call a service using the token i obtained earlier,
i see that the
userLogin map in the groovy service I called, is null
can you set the login map to the userLogin of the token
that was used so
we know who the user is?
Thanks, Hans
