Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
thiago_miranda
Contributor II
Contributor II

400 BAD REQUEST - Missing parameters

Hello!

I'm want to read information from the Qlik Proxy Service API, but keep receiving bad requests. The certificates seems ok.

First i issue a POST request to obtain a ticket and receive the ticket:

*   Trying X.X.X.X...
* Connected to qliksense.server (X.X.X.X) port 4243 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: root.pem
  CApath: /etc/ssl/certs
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*      subject: CN=qliksense.server
*      start date: Aug 10 14:17:36 2018 GMT
*      expire date: Aug 17 14:17:36 2028 GMT
*      issuer: CN=qliksense.server-CA
*      SSL certificate verify ok.
> POST /qps/{virtualproxy}/ticket?Xrfkey=1234567890123456 HTTP/1.1
Host: qliksense.server:4243
Accept: */*
Content-Type: application/json
X-Qlik-Xrfkey: 1234567890123456
Content-Length: 50

* upload completely sent off: 50 out of 50 bytes
< HTTP/1.1 201 Created
< Cache-Control: private, must-revalidate, max-age=0
< Transfer-Encoding: chunked
< Content-Type: application/json; charset=utf-8
< Expires: Wed, 02 Jan 2019 19:31:16 GMT
< Server: Microsoft-HTTPAPI/2.0
< Date: Wed, 02 Jan 2019 19:31:16 GMT
<
* Connection #0 to host qliksense.server left intact
{"UserDirectory":"DIR","UserId":"qlik","Attributes":[],"Ticket":"jpESXGEZMEshScb4","TargetUri":null}

Second, i issue a GET request (adding the Xrfkey and QlikTicket parameters and the X-Qlik-Xrfkey header):

* Hostname qliksense.server was found in DNS cache
*   Trying X.X.X.X...
* Connected to qliksense.server (X.X.X.X) port 4243 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: root.pem
  CApath: /etc/ssl/certs
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*      subject: CN=qliksense.server
*      start date: Aug 10 14:17:36 2018 GMT
*      expire date: Aug 17 14:17:36 2028 GMT
*      issuer: CN=qliksense.server-CA
*      SSL certificate verify ok.
> GET /qps/alive?Xrfkey=1234567890123456&QlikTicket=jpESXGEZMEshScb4 HTTP/1.1
Host: qliksense.server:4243
Accept: */*
X-Qlik-Xrfkey: 1234567890123456

< HTTP/1.1 400 Bad Request
< Cache-Control: private, must-revalidate, max-age=0
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=utf-8
< Expires: Wed, 02 Jan 2019 19:17:12 GMT
< Server: Microsoft-HTTPAPI/2.0
< Date: Wed, 02 Jan 2019 19:17:11 GMT
<
Missing parameter value(s)
* Connection #0 to host qliksense.server left intact

Can you help? Thank you.

Labels (1)
  • API

1 Solution

Accepted Solutions
Levi_Turner
Employee
Employee

Hey @thiago_miranda,

 

You should not need to append a ticket value to the QPS Alive check. So rather than sending:

/qps/alive?Xrfkey=1234567890123456&QlikTicket=jpESXGEZMEshScb4

Send:

/qps/alive?Xrfkey=1234567890123456

Like so:2019-01-03 08_42_52-Postman.png

 

View solution in original post

7 Replies
Levi_Turner
Employee
Employee

Hey @thiago_miranda,

 

You should not need to append a ticket value to the QPS Alive check. So rather than sending:

/qps/alive?Xrfkey=1234567890123456&QlikTicket=jpESXGEZMEshScb4

Send:

/qps/alive?Xrfkey=1234567890123456

Like so:2019-01-03 08_42_52-Postman.png

 

thiago_miranda
Contributor II
Contributor II
Author

,
 

later it hit me that QPS API doesn't need a  ticket, because we obtain a ticket from the QPS API.

But the QRS API does need a ticket.

Thank you.

Levi_Turner
Employee
Employee

Well, strictly speaking if you're hitting QRS at 4242, then it does not need a ticket since it's evaluating the X-Qlik-User header with the certificate to implicitly trust the exchange. From my understanding, if you're making a https://sense.company.com/qrs/app/full call though, then QPS needs a ticket to handle the auth and QRS inherits the userdirectory / userid values from QPS.

ryanplkam
Partner - Contributor III
Partner - Contributor III

@Levi_Turner , I'm trying to make a simple call to 4242/QRS/about?qlikTicket={qlikTicket}, but I get a 400 bad request

Is the above a valid request? Or does it not accept the qlikTicket param?

Levi_Turner
Employee
Employee

@ryanplkam : The ticket which you would have retrieved from the Qlik Proxy Service means nothing to the Repository Service:

Levi_Turner_0-1602100555976.png

So your options are:

- Go through QPS and call :443/qrs/{endpoint}?qlikticket=Ticket
- Go through QRS and call :4242/qrs/{endpoint} and pass the cert

 

ryanplkam
Partner - Contributor III
Partner - Contributor III

@Levi_Turner Super late response, but we ended up doing this:

{server}/ticket/api/hub/about?QlikTicket=0fqEjM82AccqWY-C

the 'ticket' being our ticket virtual proxy

There's no QRS in this request URL, so maybe it's the About Service API?

https://help.qlik.com/en-US/sense-developer/November2020/Subsystems/AboutServiceAPI/Content/Sense_Ab...

Thanks.

Levi_Turner
Employee
Employee

That works as well. There's a bevy of those micro-services which I tend to not use unless there's a unique use case. Glad things are good to go