And it returned below error. I had cleaned up some code and added
changes. Pl sync once and give it a try again.
"errorMessage": *"getCompanies returned error. The request contained
> 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 <
[hidden email]>
> 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 <
[hidden email]>
>> 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 <
[hidden email]>
>>> 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
>>>>
>>>>
>>>>