Do not input private or sensitive data. View Qlik Privacy & Cookie Policy.
Skip to main content

Announcements
Qlik Open Lakehouse is Now Generally Available! Discover the key highlights and partner resources here.
cancel
Showing results for 
Search instead for 
Did you mean: 
Anonymous
Not applicable

[resolved] tRestRequest with HTTP Basic Auth error on failed login

Hi,
i tried to set up a REST job with HTTP Basic login. I deployed it to karaf and the login with correct credentials works.
Problems are:
If I use wrong credentials I see an error in the logs:
2014-08-01 09:59:40,708 | ERROR | qtp9010386-58    | NamePasswordCallbackHandler      | rity.NamePasswordCallbackHandler   73 | 121 - org.apache.cxf.cxf-rt-core - 2.7.7 | Unsupported callback type org.apache.karaf.jaas.modules.publickey.PublickeyCallback

If I send no credentials I, the log shows the warning:
2014-08-01 09:19:31,459 | WARN  | qtp9010386-62    | JAASLoginInterceptor             | or.security.JAASLoginInterceptor  125 | 121 - org.apache.cxf.cxf-rt-core - 2.7.7 | No user name and/or password is available, name: null, password: null

In both cases, the connection is closed, nothing is returned to the consumer. I expected that the job returns a HTTP:401 as described in the HTTP specs.
Do I have to set any further configurations in karaf and/or my job?

Configurations are:
- TOS for ESB 5.5.1 @ Windows 7
- Karaf @ Windows 7
- Java 7
Labels (4)
1 Solution

Accepted Solutions
Anonymous
Not applicable
Author

Hi aLeXx,
thanks for the hint. As it seems that tRESTClient can handle (or workaround...) the issue, I was able to set up a (nasty) workaroud for my problem. For the interested:
Grab the "Authorization" header from the request, pass it to tRESTClient as HTTP-Auth (in 5.5.1: custom header "Authorization" with the value from the request) and point it to a simple login REST-Service, that uses the actual runtime authentication. If the authorization in tRESTClient fails, it can send an custom error to the requestor througt "ERROR"-output.

It seems, that there is actually not a bug. If logging of the tRESTRequest component is enabled, you can see, that it sends back a 401, as it should do. Apparently, there is a problem with SOAP-UI (that I used for testing). With a simple cURL request I can see, that the answer sent back from Talend Runtime is an 401 on missing or wrong credentials.

View solution in original post

5 Replies
Anonymous
Not applicable
Author

Hi paja
I have consulted to our developer and was told that it is impossible to configure the error message right now. Can you please report a jira issue in our bugtracker? Our R&D team will investigate if it is needed to improve it.
Best regards
Shong
Anonymous
Not applicable
Author

Hi Shong,
thanks for your reply. I opened bug TESB- 14086 (I would post the link, but I'm not allowed to... :-/)
Anonymous
Not applicable
Author

Hi paja
You are required to submit at least 10 posts so as to add a hyperlink. I have edited your post to include the issue link. 0683p000009MA9p.png
Best regards
Shong
Anonymous
Not applicable
Author

Hi,
i tried to set up a REST job with HTTP Basic login. I deployed it to karaf and the login with correct credentials works.
Problems are:
If I use wrong credentials I see an error in the logs:
2014-08-01 09:59:40,708 | ERROR | qtp9010386-58    | NamePasswordCallbackHandler      | rity.NamePasswordCallbackHandler   73 | 121 - org.apache.cxf.cxf-rt-core - 2.7.7 | Unsupported callback type org.apache.karaf.jaas.modules.publickey.PublickeyCallback


About error message: https://issues.apache.org/jira/browse/CXF-5940
Anyway for example tRESTClient error row returns errorCode 401 in this case.
Anonymous
Not applicable
Author

Hi aLeXx,
thanks for the hint. As it seems that tRESTClient can handle (or workaround...) the issue, I was able to set up a (nasty) workaroud for my problem. For the interested:
Grab the "Authorization" header from the request, pass it to tRESTClient as HTTP-Auth (in 5.5.1: custom header "Authorization" with the value from the request) and point it to a simple login REST-Service, that uses the actual runtime authentication. If the authorization in tRESTClient fails, it can send an custom error to the requestor througt "ERROR"-output.

It seems, that there is actually not a bug. If logging of the tRESTRequest component is enabled, you can see, that it sends back a 401, as it should do. Apparently, there is a problem with SOAP-UI (that I used for testing). With a simple cURL request I can see, that the answer sent back from Talend Runtime is an 401 on missing or wrong credentials.