Boost asio and winhttp - boost-asio

If we use boost asio library how do we send the credentials to the Web Server. For example, Winhttp library allows to set credentials using Winhttpsetcredentials. How do we do the same in boost?
http://technet.microsoft.com/en-us/query/aa384112 - winHttpsetcredentials
http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/example/http/client/async_client.cpp - Sample example
Thanks,

Just add the code to send the credentials you need to the code that sends the other headers.
request_stream << "Host: " << server << "\r\n";
request_stream << "Accept: */*\r\n";
request_stream << "Connection: close\r\n\r\n";
You can add code to send credentials anywhere in there. (Obviously, before the double line-ending that ends the headers.)

Related

NPE in Keycloak internal token-exchange

I'm trying to achieve an internal token exchange in Keycloak 17.0.1, however, the server returns an unknown error (NullPointerException).
My scenario is: I have three microservices, A, B, and C. A calls B, which is an intermediate service that needs to call service C. So, I don't want to propagate the original token (A) to call (C). Instead, I want to exchange the token, so B makes a token-exchange request to Keycloak to get a new token and then calls service C.
What I have done:
I have a client "original" who has his own client-id/client-secret
I created another client "target" and configured the policy for token exchange, assuming the "original" client in that policy.
And finally the cURL call:
curl -L -X POST 'http://localhost:8080/realms/myrealm/protocol/openid-connect/token' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=target' \
--data-urlencode 'client_secret=<< TARGET SECRET >>' \
--data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange' \
--data-urlencode 'subject_token=<< ORIGINAL CLIENT TOKEN >>' \
--data-urlencode 'requested_token_type=urn:ietf:params:oauth:token-type:refresh_token' \
--data-urlencode 'audience=original'
Response:
2022-04-19 16:05:16,154 ERROR [org.keycloak.services.error.KeycloakErrorHandler] (executor-thread-37) Uncaught server error: java.lang.NullPointerException
at org.keycloak.protocol.oidc.TokenManager.attachAuthenticationSession(TokenManager.java:539)
at org.keycloak.protocol.oidc.DefaultTokenExchangeProvider.exchangeClientToOIDCClient(DefaultTokenExchangeProvider.java:336)
at org.keycloak.protocol.oidc.DefaultTokenExchangeProvider.exchangeClientToClient(DefaultTokenExchangeProvider.java:315)
at org.keycloak.protocol.oidc.DefaultTokenExchangeProvider.tokenExchange(DefaultTokenExchangeProvider.java:233)
at org.keycloak.protocol.oidc.DefaultTokenExchangeProvider.exchange(DefaultTokenExchangeProvider.java:123)
at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.tokenExchange(TokenEndpoint.java:789)
at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.processGrantRequest(TokenEndpoint.java:204)
at jdk.internal.reflect.GeneratedMethodAccessor344.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:170)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:130)
at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:660)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:524)
at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$2(ResourceMethodInvoker.java:474)
at org.jboss.resteasy.core.interception.jaxrs.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:364)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:476)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:434)
at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:192)
at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:152)
Am I missing something?
UPDATE
The only way I've managed it to work was to "force" a session to be created in Keycloak by using a "password" grant type in the request of client A. So, I created a user foo and got a token in this way:
POST http://localhost:{{keycloak_port}}/realms/{{keycloak_realm}}/protocol/openid-connect/token
Authorization: Basic original:12345
Content-Type: application/x-www-form-urlencoded
grant_type=password
&username=foo
&password=bar
This way, a session was created for the client original and the token exchange request for the target client did work.
I'm wondering if it is a correct approach, though.
client configuration
As I'm using client_credentials OAuth2.0 flow, I had to enable the "Use Refresh Tokens For Client Credentials Grant" in Keycloak (clients/settings/OpenID Connect Compatibility Modes) and then toggle the option mentioned earlier.
Although OAuth2.0 states that refresh_tokens should not be used in this flow, I could not find another solution to this.
See attached image for more details.

RTSP: Not receiving SDP from the server after sending "describe" request

I have a Bosch camera(server) and my end goal is to get the video content description via metadata from it. I am using LwIP Raw API's(1.4.0) for this purpose. At present, I am trying to authenticate with the camera and receive the SDP so I can setup the session. However, after I authenticate by resending the describe request with the digest, I don't get any response from the server and after a while the server resets the connection. Below is the sequence of operations I perform for authentication.
Step 1: Client to Server (mcu sends 1st describe request)
DESCRIBE rtsp://service:PRBUWPCs7*f40j#192.168.1.129/?enablevideo=0&vcd=1 RTSP/1.0
CSeq: 1
User-Agent: rtsp://service:PRBUWPCs7*f40j#192.168.1.129(LIVE555 Streaming Media v2018.02.28)
Accept: application/sdp
Step 2: Server to Client (server responds with nonce for authentication, rx via callback)
Payload:RTSP/1.0 401 Unauthorized
CSeq: 1
WWW-Authenticate: Digest realm="Please log in with a valid
username",nonce="7bd251bb670e45966c415838679f778f",opaque="",stale=FALSE,algorithm=MD5
Step 3: Client to Server (mcu computes the response and resends the describe command )
DESCRIBE rtsp://service:PRBUWPCs7*f40j#192.168.1.129/?enablevideo=0&vcd=1 RTSP/1.0
CSeq: 2
Authorization: Digest username="service", realm="Please log in with a valid username", nonce="7bd251bb670e45966c415838679f778f", uri="rtsp://service:PRBUWPCs7*f40j#192.168.1.129/?enablevideo=0&vcd=1", response="4c87974de2e3ecc3d534beddef9e6962"
User-Agent: rtsp://service:PRBUWPCs7*f40j#192.168.1.129(LIVE555 Streaming Media v2018.02.28)
Accept: application/sdp
Step 4: mcu waiting for SDP, but instead receives pbuf *p as null in the receive call back function.
After a few seconds, also receives a tcp err callback with err code ERR_RST i.e. connection reset.
Could anyone please clarify if my above procedure is correct and if so, any insights on what could likely cause the camera not to respond with the SDP description leading to connection reset and receiving pbuff as NULL in the receive callback? 
Fixed it. There was an issue with md5 module.

Download attachment from Circuit Conversation via REST API

I'd like to download an attachment from the conversation via REST API (Circuit Sandbox)
If I query the Conversation Item, I can see the attachments and within that the fileID. Then, if I am logged with a user account who is a member of the conversation, I can run the following to download the attachment or paste it in the browser where I am logged to the sandbox:
'''
start chrome https://circuitsandbox.net/rest/v2/fileapi?fileid=MyFileIdHere
'''
And that works. Is there a way to achieve the same with a Bot via REST?
A regular GET request will work.
curl https://circuitsandbox.net/rest/fileapi?fileid=<fileId> \
-H "Authorization: Bearer <ACCESS_TOKEN>"
and here is the REST notation.
GET rest/fileapi?fileid=<fileId> HTTP/1.1
Host: circuitsandbox.net
Authorization: Bearer <ACCESS_TOKEN>
The access token for a bot (client credentials grant) is obtained via OAuth 2.0:
curl https://circuitsandbox.net/oauth/token \
-d 'grant_type=client_credentials&client_id=<CLIENT_ID>&client_secret=<CLIENT_SECRET>&scope=READ_CONVERSATIONS,WRITE_CONVERSATIONS'
REST notation:
POST /oauth/token HTTP/1.1
Host: circuitsandbox.net
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_id=<CLIENT_ID>&client_secret=<CLIENT_SECRET>&scope=READ_CONVERSATIONS,WRITE_CONVERSATIONS'

What does '--user' mean with curl

I'm working with an API and I have to send a POST request. I know how to set a header (-H) and (-d) is the body, but what is "--user".
If I submit this with Postman, or in a text editor with axios or just regular XMLRequest, where do I add this?
The docs say it is for regular http auth.
curl -X POST -H "Content-Type: application/json" \
--user "<client_id>:<client_secret>" \
-d '{"grant_type": "client_credentials", "scope": "public"}' \
...
Late to the party, but here goes...
You can use curl with the -v (verbose) parameter to see the headers sent. You will then see that the information provided with --user is transformed into a header, such as:
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
The text after the Basic keyword is a base64 encoded text string of the username:password combination provided with the --user parameter
To manually generate the base64 encoded credentials on Linux, you can simply call:
echo -n "username:password" | base64 -w0
For windows, save the "username:password" to a file, then use certutil.exe to create a base64 encoded file:
certutil -encode credentials.txt credentials.asc
To test this end to end, you can remove --user username:password and substitute with --header Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l and it will still authenticate just fine.
In summary, to do this manually without curl, you would need to base64 encode username:password combination. You would then need to set the HTTP Authorization header with the type as Basic along with the base64 encoded string.
--user parameter in curl used for server authentication. So if you don't define authentication type via other parameters like --digest or --negotiate, it means USER parameter for http basic authentication, it also could be combined with :PASSWORD chunk to set a password as well. The full answer on your question depends on what kind authentication is used behind API you are sending request to, and maybe curl would not be enough for it, as it support a limited set of authentication schemes ...
--user (or -u) in curl provides a basic auth to your request.
In Postman you can achieve the same result with a choice in Authorization tab.
--user "<client_id>:<client_secret>" becomes
Type: Basic Auth
Username: client_id
Password: client_secret
Specify the user name and password to use for server authentication. If you simply specify the user name, curl will prompt for a password.
If your curl request does not have any -- user, then
server that requires authentication sends back a 401 response code and an associated WWW-Authenticate: header that lists all the authentication methods that the server supports.
< HTTP/1.1 401
< WWW-Authenticate: Basic realm="oauth2/client"
Then you will know the server is using Basic authentication
You can add --basic to explicitly tell it is Basic authentication
Please refer to HTTP authentication for more information
Sometimes (depending on server implementation) the --user will negotiate a digest authenticated session. The headers for digest users are a one-time use. I believe a request to the server will first fail with a 401, but include a WWW-Authenticate response, including the digest realm, and the nonce secret. With these, a second request can be made with a new header Authorization value.
example:
Authorization: Digest username="LXAIQKBC", realm="MMS Public API", nonce="rE3sYnLXEhVMbh72JyUK7kfLIb+bAbKj", uri="/api/atlas/v1.0/groups", cnonce="YTVhM4YwMDB3ZjZjMTkxbCNiODA1ODnxZDFjOGMyMzE=", nc=00000001, qop=auth, response="7a5fcb8e4f92a665315bf62cdd87a67d", algorithm="MD5"
As an addition to Jahmic's answer, Nodejs programmers can do this to convert to base64 string:
const cryptoJS = require("crypto-js");
const base64Str = cryptoJS.enc.Base64.stringify(cryptoJS.enc.Utf8.parse(`${username}:${password}`))

Google Cloud Messaging 3rd party server gets "Missing Registration" error on sending message

I'm trying to send a message from 3rd-party server. When I send http request using curl command on shell, it works, but when I do the same thing with Ruby script, I keep on getting "Missing Registration" error. More specifically, when I type
curl --header "Authorization: key=MY_KEY" --header Content-Type:"application/json" https://android.googleapis.com/gcm/send -d "{\"registration_ids\":[\"MY_REGISTRATION_KEY\"], \"data\":{\"data1\":\"data1val\"}}"
I get the following response
{"multicast_id":5609541310450656515,"success":1,"failure":0,"canonical_ids":0,"results":[{"message_id":"0:1346184864739450%3083a1e3f9fd7ecd"}]}
, and the message is correctly received by Android device.
However, if I use the following script, the response from GCM server send error message like "Error=MissingRegistration". (using ruby version 1.9.3)
require "net/https"
require "uri"
uri = URI.parse("https://android.googleapis.com/gcm/send")
https = Net::HTTP.new(uri.host, 443)
https.use_ssl = true
https.verify_mode = OpenSSL::SSL::VERIFY_NONE
https.start{|https|
request = Net::HTTP::Post.new(uri.path)
request["Authorization"] = "key=MY_KEY"
request["Content-Type"] = "application/json"
request.set_form_data({:registration_ids => ["MY_REGISTRATION_KEY"],
:data => {data1:"data1_val"}
})
response = https.request(request)
p response.body
p response.header
}
I'm feeling like there is some problem around char encoding. I defined charset in content-type header and tried, but the result was same.
Can anyone help me?
It's about encoding. You have to set request's encoding to UTF8.