REST input is a map?

[Hans Bakker]

Hi Girish,

did some more tests and it works well with strings as in- and output,

how about Maps and Lists?

i tried the following input: {"input":{"test":"just testing"}}

and the service definition: <attribute name="input" type="Map" mode="IN"/>

then the ofbiz log below

can you have a look?

Regards,

Hans

2020-09-27 18:56:26,801 |jsse-nio-8443-exec-6
|ObjectType                    |W| Exception thrown while converting type:
org.apache.ofbiz.base.conversion.ConversionException: Could not convert
just testing to Map:
     at
org.apache.ofbiz.base.conversion.CollectionConverters$StringToMap.convert(CollectionConverters.java:172)
~[main/:?]
     at
org.apache.ofbiz.base.conversion.CollectionConverters$StringToMap.convert(CollectionConverters.java:164)
~[main/:?]
     at
org.apache.ofbiz.base.util.ObjectType.simpleTypeOrObjectConvert(ObjectType.java:350)
~[main/:?]
     at
org.apache.ofbiz.service.ModelService.makeValid(ModelService.java:1589)
~[main/:?]
     at
org.apache.ofbiz.service.ModelService.makeValid(ModelService.java:1516)
~[main/:?]
     at
org.apache.ofbiz.service.ModelService.makeValid(ModelService.java:1503)
~[main/:?]
     at
org.apache.ofbiz.service.DispatchContext.makeValidContext(DispatchContext.java:190)
~[main/:?]
     at
org.apache.ofbiz.service.DispatchContext.makeValidContext(DispatchContext.java:162)
~[main/:?]
     at
org.apache.ofbiz.ws.rs.ServiceRequestProcessor.process(ServiceRequestProcessor.java:64)
~[main/:?]
     at
org.apache.ofbiz.ws.rs.resources.OFBizServiceResource.doGet(OFBizServiceResource.java:120)
~[main/:?]
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[?:1.8.0_265]
     at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[?:1.8.0_265]
     at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:1.8.0_265]
     at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_265]
     at
org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52)
~[jersey-server-2.31.jar:?]
     at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:124)
[jersey-server-2.31.jar:?]
     at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:167)
[jersey-server-2.31.jar:?]
     at
org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:176)
[jersey-server-2.31.jar:?]
     at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79)
[jersey-server-2.31.jar:?]
     at
org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:469)
[jersey-server-2.31.jar:?]
     at
org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:391)
[jersey-server-2.31.jar:?]
     at
org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:80)
[jersey-server-2.31.jar:?]
     at
org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:253)
[jersey-server-2.31.jar:?]
     at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
[jersey-common-2.31.jar:?]
     at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
[jersey-common-2.31.jar:?]
     at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
[jersey-common-2.31.jar:?]
     at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
[jersey-common-2.31.jar:?]
     at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
[jersey-common-2.31.jar:?]
     at
org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
[jersey-common-2.31.jar:?]
     at
org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:232)
[jersey-server-2.31.jar:?]
     at
org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:680)
[jersey-server-2.31.jar:?]
     at
org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:394)
[jersey-container-servlet-core-2.31.jar:?]
     at
org.glassfish.jersey.servlet.ServletContainer.serviceImpl(ServletContainer.java:386)
[jersey-container-servlet-core-2.31.jar:?]
     at
org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:561)
[jersey-container-servlet-core-2.31.jar:?]
     at
org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:502)
[jersey-container-servlet-core-2.31.jar:?]
     at
org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:439)
[jersey-container-servlet-core-2.31.jar:?]
     at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
[tomcat-catalina-9.0.37.jar:9.0.37]
     at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
[tomcat-catalina-9.0.37.jar:9.0.37]
     at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
[tomcat-catalina-9.0.37.jar:9.0.37]
     at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
[tomcat-catalina-9.0.37.jar:9.0.37]
     at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
[tomcat-catalina-9.0.37.jar:9.0.37]
     at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
[tomcat-catalina-9.0.37.jar:9.0.37]
     at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
[tomcat-catalina-9.0.37.jar:9.0.37]
     at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
[tomcat-catalina-9.0.37.jar:9.0.37]
     at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690)
[tomcat-catalina-9.0.37.jar:9.0.37]
     at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
[tomcat-catalina-9.0.37.jar:9.0.37]
     at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373)
[tomcat-coyote-9.0.37.jar:9.0.37]
     at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
[tomcat-coyote-9.0.37.jar:9.0.37]
     at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
[tomcat-coyote-9.0.37.jar:9.0.37]
     at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1589)
[tomcat-coyote-9.0.37.jar:9.0.37]
     at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
[tomcat-coyote-9.0.37.jar:9.0.37]
     at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[?:1.8.0_265]
     at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[?:1.8.0_265]
     at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
[tomcat-util-9.0.37.jar:9.0.37]
     at java.lang.Thread.run(Thread.java:748) [?:1.8.0_265]
2020-09-27 18:56:26,808 |jsse-nio-8443-exec-6
|ModelService                  |W| [ModelService.makeValid] : Type
conversion of field [input] to type [Map] failed for value "just
testing": org.apache.ofbiz.base.util.GeneralException: Could not convert
just testing to Map:  (Could not convert just testing to Map: )
2020-09-27 18:56:26,808 |jsse-nio-8443-exec-6
|ObjectType                    |W| Exception thrown while converting type:
org.apache.ofbiz.base.conversion.ConversionException: Could not convert
just testing to Map:
     at
org.apache.ofbiz.base.conversion.CollectionConverters$StringToMap.convert(CollectionConverters.java:172)
~[main/:?]
     at
org.apache.ofbiz.base.conversion.CollectionConverters$StringToMap.convert(CollectionConverters.java:164)
~[main/:?]
     at
org.apache.ofbiz.base.util.ObjectType.simpleTypeOrObjectConvert(ObjectType.java:350)
~[main/:?]
     at
org.apache.ofbiz.service.ModelService.makeValid(ModelService.java:1589)
~[main/:?]

[grv]

Hi Hans

Maps and Lists work quite well. There is a difference in how you send the
JSON to a service that's listed as GET vs (PUT, PATCH or POST).

Yours is probably GET and you need to send the JSON urlencoded.

<service name=*"demoMapService"* engine=*"java"* require-new-transaction=
*"true"* max-retry=*"3"* export=*"true"* action=*"GET"*

            location=
*"org.apache.ofbiz.rest.demo.ProductAndCatalogServices"* invoke=
*"demoMapService"*>

        <description>Gets a product feature</description>

        <attribute name=*"input"* type=*"Map"* mode=*"IN"* optional=
*"false"*/>

        <attribute name=*"output"* type=*"String"* mode=*"OUT"* optional=
*"true"*/>

 </service>


curl -G -X  GET https://localhost:8443/rest/services/demoMapService
--data-urlencode 'inParams={"input":{"test":"just testing"}}' -H "Accept: ap

plication/json" -H "Authorization: Bearer $token" --insecure

Above cURL works if the service is defined as GET.
However, if it were defined as POST, you will be sending like this -

<service name=*"demoMapService"* engine=*"java"* require-new-transaction=
*"true"* max-retry=*"3"* export=*"true"* action=*"POST"*

            location=
*"org.apache.ofbiz.rest.demo.ProductAndCatalogServices"* invoke=
*"demoMapService"*>

        <description>Gets a product feature</description>

        <attribute name=*"input"* type=*"Map"* mode=*"IN"* optional=
*"false"*/>

        <attribute name=*"output"* type=*"String"* mode=*"OUT"* optional=
*"true"*/>

</service>

curl -X POST https://localhost:8443/rest/services/demoMapService -d
'{"input":{"test":"just testing"}}' -H "Content-Type: application/json" -H "

Accept: application/json" -H "Authorization: Bearer $token" --insecure

Best,
Girish
HotWax Systems

On Sun, Sep 27, 2020 at 5:34 PM Hans Bakker <[hidden email]>
wrote:

> Hi Girish,
>
> did some more tests and it works well with strings as in- and output,
>
> how about Maps and Lists?
>
> i tried the following input: {"input":{"test":"just testing"}}
>
> and the service definition: <attribute name="input" type="Map" mode="IN"/>
>
> then the ofbiz log below
>
> can you have a look?
>
> Regards,
>
> Hans
>
> 2020-09-27 18:56:26,801 |jsse-nio-8443-exec-6
> |ObjectType                    |W| Exception thrown while converting type:
> org.apache.ofbiz.base.conversion.ConversionException: Could not convert
> just testing to Map:
>      at
> org.apache.ofbiz.base.conversion.CollectionConverters$StringToMap.convert(CollectionConverters.java:172)
>
> ~[main/:?]
>      at
> org.apache.ofbiz.base.conversion.CollectionConverters$StringToMap.convert(CollectionConverters.java:164)
>
> ~[main/:?]
>      at
> org.apache.ofbiz.base.util.ObjectType.simpleTypeOrObjectConvert(ObjectType.java:350)
>
> ~[main/:?]
>      at
> org.apache.ofbiz.service.ModelService.makeValid(ModelService.java:1589)
> ~[main/:?]
>      at
> org.apache.ofbiz.service.ModelService.makeValid(ModelService.java:1516)
> ~[main/:?]
>      at
> org.apache.ofbiz.service.ModelService.makeValid(ModelService.java:1503)
> ~[main/:?]
>      at
> org.apache.ofbiz.service.DispatchContext.makeValidContext(DispatchContext.java:190)
>
> ~[main/:?]
>      at
> org.apache.ofbiz.service.DispatchContext.makeValidContext(DispatchContext.java:162)
>
> ~[main/:?]
>      at
> org.apache.ofbiz.ws.rs.ServiceRequestProcessor.process(ServiceRequestProcessor.java:64)
>
> ~[main/:?]
>      at
> org.apache.ofbiz.ws.rs.resources.OFBizServiceResource.doGet(OFBizServiceResource.java:120)
>
> ~[main/:?]
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:1.8.0_265]
>      at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> ~[?:1.8.0_265]
>      at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> ~[?:1.8.0_265]
>      at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_265]
>      at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52)
>
> ~[jersey-server-2.31.jar:?]
>      at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:124)
>
> [jersey-server-2.31.jar:?]
>      at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:167)
>
> [jersey-server-2.31.jar:?]
>      at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:176)
>
> [jersey-server-2.31.jar:?]
>      at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79)
>
> [jersey-server-2.31.jar:?]
>      at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:469)
>
> [jersey-server-2.31.jar:?]
>      at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:391)
>
> [jersey-server-2.31.jar:?]
>      at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:80)
>
> [jersey-server-2.31.jar:?]
>      at
> org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:253)
> [jersey-server-2.31.jar:?]
>      at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
> [jersey-common-2.31.jar:?]
>      at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
> [jersey-common-2.31.jar:?]
>      at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
> [jersey-common-2.31.jar:?]
>      at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
> [jersey-common-2.31.jar:?]
>      at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
> [jersey-common-2.31.jar:?]
>      at
> org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
>
> [jersey-common-2.31.jar:?]
>      at
> org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:232)
> [jersey-server-2.31.jar:?]
>      at
> org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:680)
>
> [jersey-server-2.31.jar:?]
>      at
> org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:394)
>
> [jersey-container-servlet-core-2.31.jar:?]
>      at
> org.glassfish.jersey.servlet.ServletContainer.serviceImpl(ServletContainer.java:386)
>
> [jersey-container-servlet-core-2.31.jar:?]
>      at
> org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:561)
>
> [jersey-container-servlet-core-2.31.jar:?]
>      at
> org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:502)
>
> [jersey-container-servlet-core-2.31.jar:?]
>      at
> org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:439)
>
> [jersey-container-servlet-core-2.31.jar:?]
>      at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>
> [tomcat-catalina-9.0.37.jar:9.0.37]
>      at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>
> [tomcat-catalina-9.0.37.jar:9.0.37]
>      at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
>
> [tomcat-catalina-9.0.37.jar:9.0.37]
>      at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
>
> [tomcat-catalina-9.0.37.jar:9.0.37]
>      at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
>
> [tomcat-catalina-9.0.37.jar:9.0.37]
>      at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
>
> [tomcat-catalina-9.0.37.jar:9.0.37]
>      at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
>
> [tomcat-catalina-9.0.37.jar:9.0.37]
>      at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
>
> [tomcat-catalina-9.0.37.jar:9.0.37]
>      at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690)
>
> [tomcat-catalina-9.0.37.jar:9.0.37]
>      at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
>
> [tomcat-catalina-9.0.37.jar:9.0.37]
>      at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373)
> [tomcat-coyote-9.0.37.jar:9.0.37]
>      at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
>
> [tomcat-coyote-9.0.37.jar:9.0.37]
>      at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
>
> [tomcat-coyote-9.0.37.jar:9.0.37]
>      at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1589)
>
> [tomcat-coyote-9.0.37.jar:9.0.37]
>      at
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
>
> [tomcat-coyote-9.0.37.jar:9.0.37]
>      at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> [?:1.8.0_265]
>      at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>
> [?:1.8.0_265]
>      at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>
> [tomcat-util-9.0.37.jar:9.0.37]
>      at java.lang.Thread.run(Thread.java:748) [?:1.8.0_265]
> 2020-09-27 18:56:26,808 |jsse-nio-8443-exec-6
> |ModelService                  |W| [ModelService.makeValid] : Type
> conversion of field [input] to type [Map] failed for value "just
> testing": org.apache.ofbiz.base.util.GeneralException: Could not convert
> just testing to Map:  (Could not convert just testing to Map: )
> 2020-09-27 18:56:26,808 |jsse-nio-8443-exec-6
> |ObjectType                    |W| Exception thrown while converting type:
> org.apache.ofbiz.base.conversion.ConversionException: Could not convert
> just testing to Map:
>      at
> org.apache.ofbiz.base.conversion.CollectionConverters$StringToMap.convert(CollectionConverters.java:172)
>
> ~[main/:?]
>      at
> org.apache.ofbiz.base.conversion.CollectionConverters$StringToMap.convert(CollectionConverters.java:164)
>
> ~[main/:?]
>      at
> org.apache.ofbiz.base.util.ObjectType.simpleTypeOrObjectConvert(ObjectType.java:350)
>
> ~[main/:?]
>      at
> org.apache.ofbiz.service.ModelService.makeValid(ModelService.java:1589)
> ~[main/:?]
>
>

[Hans Bakker]

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

[grv]

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

[Hans Bakker]

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] <mailto:[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
>
>

[grv]

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

[Hans Bakker]

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] <mailto:[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] <mailto:[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
>>
>>

[grv]

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

[Hans Bakker]

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]
> <mailto:[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] <mailto:[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]
>>>         <mailto:[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
>>>
>>>

[grv]

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 <[hidden email]>
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 <[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
>>>>
>>>>
>>>>

[Hans Bakker]

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 <[hidden email]>
> 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 <[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
>>>>>
>>>>>
>>>>>