ofbiz REST error messages, was: REST, how about 'Login' map

[Hans Bakker <h....@antwebsystems.com>]

Hi Girish,

again thanks for your help.

I updated my version here, and show the flutter Dio error messages 
better as explained at:
https://pub.dev/packages/dio#handling-errors

and now these error messages are received properly,

Thanks again,

Regards,
Hans Bakker
antwebsystems.com

On 10/2/20 8:25 AM, Girish Vasmatkar wrote:
> Hi Hans, if service is returning an error, it should get converted into a
> 422.
>
> I took your getCompanies service example from your plugin and modified the
> service as below
>
> def getCompanies() {
>      Map result = success()
>      logInfo("service starting with ${parameters.input}")
>      result.companies = parameters.input
>      return error("this is the error message")
> }
>
> And accessed it like
>
> https://localhost:8443/rest
> /services/getCompanies?inParams=%7B%0A%20%20%22input%22%3A%20%22string%22%0A%7D
>
> And it returned below error. I had cleaned up some code and added
> additional handling yesterday, so might be possible you don't have those
> changes. Pl sync once and give it a try again.
>
> {
>
>      "statusCode": 422,
>
>      "statusDescription": *"Unprocessable Entity"*,
>
>      "errorType": *"ServiceError"*,
>
>      "errorMessage": *"getCompanies returned error. The request contained
> invalid information and could not be processed."*,
>
>      "errorDescription": *"this is the error message"*
>
> }
>
> Let me know if it still does not work for you and additionally provide your
> service def for me to take a more closer look.
>
> Best,
> Girish
>
>
>
>
>
>
>
>
> On Fri, Oct 2, 2020 at 6:07 AM Hans Bakker <h....@antwebsystems.com>
> wrote:
>
>> 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 <h....@antwebsystems.com>
>> 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 <h....@antwebsystems.com>
>>> 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 <h....@antwebsystems.com>
>>>> 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
>>>>>
>>>>>
>>>>>