curl -X POST -i -u ditto:foobar -H 'Content-Type: application/json' -d '{
"targetActorSelection": "/system/sharding/connection",
"headers": {
"aggregate": false
},
"piggybackCommand": {
"type": "connectivity.commands:testConnection",
"connection": {
"id": "'$MY_DEVICE'",
"connectionType": "amqp-10",
"connectionStatus": "open",
"uri": "amqp://consumer%40HONO:my-pwd#$AMQP_NETWORK_IP:15672",
"failoverEnabled": true,
"sources": [{
"addresses": [
"telemetry/$MY_TENANT",
"event/$MY_TENANT"
]
}]
}
}
}' http://localhost:8080/devops/piggyback/connectivity?timeout=8000
Errors Prompted:
HTTP/1.1 401 Unauthorized
Server: nginx/1.13.12
Date: Sun, 19 Jan 2020 11:20:52 GMT
Content-Type: text/plain; charset=UTF-8
Content-Length: 38
Connection: keep-alive
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
WWW-Authenticate: Basic realm="DITTO-DEVOPS",charset=UTF-8
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Accept,Authorization,Cache-Control,Content-Type,Content-Length,DNT,If-Match,If-Modified-Since,If-None-Match,Keep-Alive,Origin,User-Agent,X-Requested-With
The supplied authentication is invalid
If your question is (which I have to assume seeing no question) what the correct credentials are, please have a look at the Eclipse Ditto operating documentation:
username: devops, password: foobar
Related
I'm trying to send a GET request to the Binance API. But I'm getting this output in my terminal instead of the data:
Response { url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("api.binance.com")), port: None, path: "/api/v3/exchangeInfo", query: Some("symbol=BNBBTC"), fragment: None }, status: 200, headers: {"content-type": "application/json;charset=UTF-8", "content-length": "1515", "connection": "keep-alive", "date": "Thu, 23 Dec 2021 23:28:24 GMT", "server": "nginx", "vary": "Accept-Encoding", "x-mbx-uuid": "1244d760-2c41-46df-910f-b95c4a312bc2", "x-mbx-used-weight": "10", "x-mbx-used-weight-1m": "10", "strict-transport-security": "max-age=31536000; includeSubdomains", "x-frame-options": "SAMEORIGIN", "x-xss-protection": "1; mode=block", "x-content-type-options": "nosniff", "content-security-policy": "default-src 'self'", "x-content-security-policy": "default-src 'self'", "x-webkit-csp": "default-src 'self'", "cache-control": "no-cache, no-store, must-revalidate", "pragma": "no-cache", "expires": "0", "access-control-allow-origin": "*", "access-control-allow-methods": "GET, HEAD, OPTIONS", "x-cache": "Miss from cloudfront", "via": "1.1 08b9c2fd11813ffdb8fa03129d0a465d.cloudfront.net (CloudFront)", "x-amz-cf-pop": "FRA56-C2", "x-amz-cf-id": "EBp6UQUM3B2Lz0iAoPM88INjL4C0ugIgxmaoTPzi0Q4WPxfG46p8Yw=="} }
My code looks like this:
async fn main() {
let client = Client::new();
let res = client.get("https://api.binance.com/api/v3/exchangeInfo?symbol=BNBBTC")
// .header(USER_AGENT, "Mozilla/5.0 (Macintosh; Intel Mac OS X 12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36")
// .header(CONTENT_TYPE, "application/json")
// .header(CACHE_CONTROL, "no-store")
// .header(PRAGMA, "no-cache")
.send().await;
println!("{:?}", res.unwrap());
}
What am I doing wrong?
The Response that you're printing is basically just the initial HTTP info (e.g. status and headers). You'll need to wait for the payload as well using methods depending on what you're expecting:
bytes/bytes_stream/chunk to get the raw data
text/text_with_charset to get the data as a string
json to deserialize the data into a structured type (see the docs for serde_json for more info)
In this case it looks like you're getting a JSON payload so using .json() into a deserializable type sounds like the right way to go, but if your only goal is to print it then .text() is probably the simpler approach.
async fn main() {
let client = Client::new();
let res = client
.get("https://api.binance.com/api/v3/exchangeInfo?symbol=BNBBTC")
.send()
.await
.expect("failed to get response")
.text()
.await
.expect("failed to get payload");
println!("{}", res);
}
Related:
Where is the body of a HTTP response stored? (with Rust + reqwest)
I have API Gateway set up to serve some files from S3 bucket with Lambda. When I try to request non-existing files, API Gateway sometimes responds with 403 Forbidden (most of the times and doesn't even trigger Lambda function) and sometimes with 404 Not Found error (I'd like to trigger 404 in such cases).
My Lambda function is very simple:
exports.handler = async event => {
try {
const Bucket = 'testing-bucket';
const Key = `${event.documentType}/${event.requestParams.document}`;
const file = await s3.getObject({ Bucket, Key }).promise();
return {
body: file.Body.toString('base64'),
headers: {
'Content-Disposition': `attachment; filename=test.jpg`,
'Content-Length': file.ContentLength,
'Content-Type': file.ContentType,
},
statusCode: 200,
isBase64Encoded: true,
};
} catch (e) {
return {
body: JSON.stringify({ message: `[${e.code}] ${e.message}` }),
statusCode: e.statusCode,
};
}
};
IAM Role attached to Lambda function is configured in this way:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::testing-bucket",
"arn:aws:s3:::testing-bucket/*"
]
}
]
}
Caching is completely disabled in API Gateway and the command I've been trying to test this out is:
curl -X GET -H 'Authorization: 123xyz' -H 'Accept: image/jpeg' -H 'Cache-Control: no-cache' -I https://test.com/existing_folder/non-existing-file.xxx
Responses are:
HTTP/2 403
content-type: application/json
content-length: 60
date: Mon, 07 Oct 2019 10:32:30 GMT
x-amzn-requestid: ae870104-9045-4c23-9794-226992bad591
x-amzn-errortype: AccessDeniedException
x-amz-apigw-id: BMAZwGSyoAMFftw=
x-cache: Error from cloudfront
via: 1.1 ccf34ecc11e5579d8083b17d9d39a622.cloudfront.net (CloudFront)
x-amz-cf-pop: LHR62-C2
x-amz-cf-id: zgtgfJX9TQLcI8F2RLWdgTz-RN_1j7MXblQ1498ucoeFY3dhjitOdg==
and
HTTP/2 404
content-type: application/json
content-length: 59
date: Mon, 07 Oct 2019 10:32:31 GMT
x-amzn-requestid: 2de49681-4f21-4cd1-989c-9b36327badb1
x-amz-apigw-id: BMAZ5E52IAMFwEg=
x-amzn-trace-id: Root=1-5d9b143f-aadf0a24a5f60f4c939b77c0;Sampled=0
x-cache: Error from cloudfront
via: 1.1 be00537a2361673ea48963d6e04d04a1.cloudfront.net (CloudFront)
x-amz-cf-pop: LHR62-C2
x-amz-cf-id: 9VI26GH3-ZuJSQrEt5Fc7EjuMt8IV0TPzPwna8dvvr6UtsgiqwwIkw==
How to make API Gateway respond in consistent way?
UPDATE:
After observing API Gateway logs and trying to spam the same curl command for existing and non-existing files couple of times in a row, this was the output for non-existing file (timestamps are intact):
# curl -X GET -H 'Authorization: 123xyz' -H 'Accept: image/jpeg' -H 'cache-control: private, no-cache, no-store, max-age=1, s-maxage=1' https://my.url/foo/nobar
{
"requestId": "d19602e8-3a32-4445-b9e6-99f05a59fac4",
"ip": "redacted",
"caller": "-",
"user": "-",
"requestTime": "08/Oct/2019:00:05:03 +0000",
"httpMethod": "GET",
"resourcePath": "/foo/{bar}",
"status": "404",
"protocol": "HTTP/1.1",
"responseLength": "59"
}
# and
{
"requestId": "b33bf6c7-55db-4e1f-b4e4-b1e826139556",
"ip": "redacted",
"caller": "-",
"user": "-",
"requestTime": "08/Oct/2019:00:05:05 +0000",
"httpMethod": "GET",
"resourcePath": "/foo/{bar}",
"status": "403",
"protocol": "HTTP/1.1",
"responseLength": "60"
}
and for existing file:
# curl -X GET -H 'Authorization: 123xyz' -H 'Accept: image/jpeg' -H 'cache-control: private, no-cache, no-store, max-age=1, s-maxage=1' https://my.url/foo/bar
{
"requestId": "122ef31e-c587-470c-a0b5-51c6d9838fe4",
"ip": "redacted",
"caller": "-",
"user": "-",
"requestTime": "07/Oct/2019:23:58:35 +0000",
"httpMethod": "GET",
"resourcePath": "/foo/{bar}",
"status": "403",
"protocol": "HTTP/1.1",
"responseLength": "60"
}
# and then later
{
"requestId": "c8ad1b40-006f-4d03-9d10-c6d91e366380",
"ip": "redacted",
"caller": "-",
"user": "-",
"requestTime": "07/Oct/2019:23:59:58 +0000",
"httpMethod": "GET",
"resourcePath": "/foo/{bar}",
"status": "200",
"protocol": "HTTP/1.1",
"responseLength": "80280"
}
I finally got some time to get back to this issue and it looks like the problem was all along in "authorizer" function which had caching enabled, once disabled, my responses started to respond in a consistent way.
You can manage the response yourself. You can check if the file doesn't exist after your await and respond a 404. Something like this: (Code not tested)
exports.handler = async event => {
try {
const Bucket = 'testing-bucket';
const Key = `${event.documentType}/${event.requestParams.document}`;
const file = await s3.getObject({ Bucket, Key }).promise();
if (!file) {
return {
body: {error: 'File not found'},
headers: {
'Content-Type': 'application/json'
}
statusCode: 400,
};
}
return {
body: file.Body.toString('base64'),
headers: {
'Content-Disposition': `attachment; filename=test.jpg`,
'Content-Length': file.ContentLength,
'Content-Type': file.ContentType,
},
statusCode: 200,
isBase64Encoded: true,
};
} catch (e) {
return {
body: JSON.stringify({ message: `[${e.code}] ${e.message}` }),
statusCode: e.statusCode,
};
}
};
So when I wrote my lambda to process s3 downloads, I did stick with promise chaining so that I could debug easier...have you tried the other method?
return s3.getObject({ Bucket, Key }).promise().then((s3Response) => {
console.log(s3Response.Body.toString());
}).catch((err) => {
console.log(err);
});
I have a feeling there is something happening in your promise that's causing it to come back to quick and it's failing or something along those lines.
I’m trying to script adding a permission in Azure AD, and I’m getting a 403 for some reason.
Here’s the command:
az ad app permission grant --id 934b23f2-ab55-4876-83ce-b38e9966ea53 --api 2ac352a9-b35a-4db8-bbce-84d9245faa45
Here’s the debug output:
msrest.http_logger : Request URL: 'https://graph.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47/oauth2PermissionGrants?api-version=1.6'
msrest.http_logger : Request method: 'POST'
msrest.http_logger : Request headers:
msrest.http_logger : 'Accept': 'application/json'
msrest.http_logger : 'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger : 'accept-language': 'en-US'
msrest.http_logger : 'Content-Length': '323'
msrest.http_logger : 'User-Agent': 'python/3.6.6 (Windows-10-10.0.18362-SP0) msrest/0.6.6 msrest_azure/0.6.0 azure-graphrbac/0.60.0 Azure-SDK-For-Python AZURECLI/2.0.62'
msrest.http_logger : Request body:
msrest.http_logger : {"odata.type": "Microsoft.DirectoryServices.OAuth2PermissionGrant", "clientId": "874bf2e7-d191-4d86-ba64-234c885c703a", "consentType": "AllPrincipals", "resourceId": "e7c4266c-e7c0-440f-910a-2557f24b842c", "scope": "user_impersonation", "startTime": "2019-04-18T00:11:56.102063", "expiryTime": "2020-04-18T00:11:56.102063"}
msrest.universal_http : Configuring redirects: allow=True, max=30
msrest.universal_http : Configuring request: timeout=100, verify=True, cert=None
msrest.universal_http : Configuring proxies: ''
msrest.universal_http : Evaluate proxies against ENV settings: True
urllib3.connectionpool : Starting new HTTPS connection (1): graph.windows.net:443
urllib3.connectionpool : https://graph.windows.net:443 "POST /72f988bf-86f1-41af-91ab-2d7cd011db47/oauth2PermissionGrants?api-version=1.6 HTTP/1.1" 403 219
msrest.http_logger : Response status: 403
msrest.http_logger : Response headers:
msrest.http_logger : 'Cache-Control': 'no-cache'
msrest.http_logger : 'Pragma': 'no-cache'
msrest.http_logger : 'Content-Type': 'application/json; odata=minimalmetadata; streaming=true; charset=utf-8'
msrest.http_logger : 'Expires': '-1'
msrest.http_logger : 'ocp-aad-diagnostics-server-name': 'flQBgrwiZdgfrwyQn7i7mb8tOHe8Zm56rla4LDh9+Zw='
msrest.http_logger : 'request-id': 'e514bba2-7cc9-47e7-bd16-ff1ea17fbad8'
msrest.http_logger : 'client-request-id': '924eb878-616e-11e9-8077-f26e0bc197ab'
msrest.http_logger : 'x-ms-dirapi-data-contract-version': '1.6'
msrest.http_logger : 'ocp-aad-session-key': '-RrCLfYgOSFwqxz4IBLGEBFBrYfXBZbU8zNwiCGag-dWYfm6EGWjClVXFX9LjmWphFkDKZaqQP39ko2PuX_K4DXuqK1NwUB5wayM8e5wnXvaSoYQW1B4nwJDR7JAHnwU.e2QPHdU1fQSwX4_tnWM81ajF8thbjmTeEPBE9HPtOJI'
msrest.http_logger : 'DataServiceVersion': '3.0;'
msrest.http_logger : 'Strict-Transport-Security': 'max-age=31536000; includeSubDomains'
msrest.http_logger : 'Access-Control-Allow-Origin': '*'
msrest.http_logger : 'X-AspNet-Version': '4.0.30319'
msrest.http_logger : 'X-Powered-By': 'ASP.NET'
msrest.http_logger : 'Duration': '545850'
msrest.http_logger : 'Date': 'Thu, 18 Apr 2019 00:11:55 GMT'
msrest.http_logger : 'Content-Length': '219'
msrest.http_logger : Response content:
msrest.http_logger : {"odata.error":{"code":"Authorization_RequestDenied","message":{"lang":"en","value":"Insufficient privileges to complete the operation."},"requestId":"e514bba2-7cc9-47e7-bd16-ff1ea17fbad8","date":"2019-04-18T00:11:56"}}
msrest.exceptions : Operation failed with status: 'Forbidden'. Details: 403 Client Error: Forbidden for url: https://graph.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47/oauth2PermissionGrants?api-version=1.6
cli.azure.cli.core.util : Operation failed with status: 'Forbidden'. Details: 403 Client Error: Forbidden for url: https://graph.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47/oauth2PermissionGrants?api-version=1.6
Operation failed with status: 'Forbidden'. Details: 403 Client Error: Forbidden for url: https://graph.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47/oauth2PermissionGrants?api-version=1.6
az_command_data_logger : exit code: 1
telemetry.save : Save telemetry record of length 2468 in cache
telemetry.check : Negative: The C:\Users\mikebaz\.azure\telemetry.txt was modified at 2019-04-17 20:04:03.430973, which in less than 600.000000 s
command ran in 2.421 seconds.
And this is what I’m trying to grant:
[
{
"additionalProperties": null,
"expiryTime": "",
"resourceAccess": [
{
"additionalProperties": null,
"id": "4b7cb559-04e7-4d6e-8b59-362ceccc6a89",
"type": "Scope"
}
],
"resourceAppId": "2ac352a9-b35a-4db8-bbce-84d9245faa45"
}
]
I can successfully do the grant in the Portal (that’s how I can get the grant details above), so I know I am allowed to do the grant.
Any thoughts about what I’m missing here?
At least one issue that I notice is that value for --api parameter in your command is probably not correct.
In Json that you mention is the working copy from Portal, resourceAppId is 2ac352a9-b35a-4db8-bbce-84d9245faa45 so that should be the value of --api parameter or target API in your command.
[
{
"additionalProperties": null,
"expiryTime": "",
"resourceAccess": [
{
"additionalProperties": null,
"id": "4b7cb559-04e7-4d6e-8b59-362ceccc6a89",
"type": "Scope"
}
],
"resourceAppId": "2ac352a9-b35a-4db8-bbce-84d9245faa45"
}
]
Also make sure that you have the 934b23f2-ab55-4876-83ce-b38e9966ea53 is the applicationid or objectid for your application.
az ad app permission grant --id 934b23f2-ab55-4876-83ce-b38e9966ea53 --api 2ac352a9-b35a-4db8-bbce-84d9245faa45 --scope user_impersonation --consent-type AllPrincipals
How can I log cookies that are stored in a cookie jar using the request-promise npm module.
I have tried printing the cookie jar variable but as expected that does not work.
How I am creating the jar,
var request = require('request-promise');
var sess = request.jar()
The code sending the request,
request({url: myurl, jar: sess}, function () {
request(
{
url: 'myurl',
method: 'POST',
headers: [
{
"Accept": "application/json",
}
],
postData: {
"xqr":"1"
}
}
)
I expect all the cookies used to send my request to be printed out using console.log()
request uses tough-cookie internally. So you can easily access to tough-cookie store which is an abstract class and use its prototype function getAllCookies.
function logCookies(jar){
jar._jar.store.getAllCookies(function(err, cookieArray) {
if(err) throw new Error("Failed to get cookies");
console.log(JSON.stringify(cookieArray, null, 4));
});
}
And this will log all cookies and its properties.
[
{
"key": "1P_JAR",
"value": "1P_JAR_VALUE",
"expires": "2019-01-23T20:09:38.000Z",
"domain": "google.com",
"path": "/",
"hostOnly": false,
"creation": "2018-12-24T20:09:37.800Z",
"lastAccessed": "2018-12-24T20:09:38.097Z"
},
{
"key": "NID",
"value": "NID_VALUE",
"expires": "2019-06-25T20:09:38.000Z",
"domain": "google.com",
"path": "/",
"httpOnly": true,
"hostOnly": false,
"creation": "2018-12-24T20:09:37.802Z",
"lastAccessed": "2018-12-24T20:09:38.098Z"
}
]
If you only want to get raw cookie string you can just simply use
console.log(cookieArray.map(cookie => cookie.toString()))
And it will give you
[
'1P_JAR=1P_JAR_VALUE; Expires=Wed, 23 Jan 2019 20:15:02 GMT; Domain=google.com; Path=/',
'NID=NID_VALUE; Expires=Tue, 25 Jun 2019 20:15:02 GMT; Domain=google.com; Path=/; HttpOnly'
]
After login to the Keycloak Jaeger(realm) client, the keycloak server doesn't navigate to the Jaeger UI path -> localhost:16686.
Request URL: http://localhost:8080/auth/realms/jaeger/protocol/openid-connect/auth?response_type=code&client_id=proxy-jaeger&redirect_uri=http%3A%2F%2Flocalhost%3A8180%2F&state=79c00178-ca7c-4dfd-9c22-5007690486de&login=true&scope=openid
Request Method: GET
Status Code: 302 Found
It seems keycloak verifies the user (see below code)
HTTP/1.1 302 Found
Connection: keep-alive
Cache-Control: no-store, must-revalidate, max-age=0
Set-Cookie: AUTH_SESSION_ID=139b5028-8d19-4ab4-b657-b08ff810a8eb.f3faed1bab38; Version=1; Path=/auth/realms/jaeger/; HttpOnly
Set-Cookie: KC_RESTART=eyJhbGciOiJIUzI1NiIsImtpZCIgOiAiNDEzYjIyMzEtZmVlMi00ZWJiLWI3YjktNzU2YTcxNzNiZTc5In0.eyJjaWQiOiJwcm94eS1qYWVnZXIiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwOi8vbG9jYWxob3N0OjgxODAvIiwiYWN0IjoiQVVUSEVOVElDQVRFIiwibm90ZXMiOnsic2NvcGUiOiJvcGVuaWQiLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvamFlZ2VyIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUiLCJjb2RlX2NoYWxsZW5nZV9tZXRob2QiOiJwbGFpbiIsInJlZGlyZWN0X3VyaSI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODE4MC8iLCJzdGF0ZSI6Ijc5YzAwMTc4LWNhN2MtNGRmZC05YzIyLTUwMDc2OTA0ODZkZSIsImNsaWVudF9yZXF1ZXN0X3BhcmFtX2xvZ2luIjoidHJ1ZSJ9fQ.mdWPMhPcEVFVTwoYDpTC_hHspdSOZrek-CLU05Whx74; Version=1; Path=/auth/realms/jaeger/; HttpOnly
Set-Cookie: KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/jaeger/; HttpOnly
Set-Cookie: KEYCLOAK_IDENTITY=eyJhbGciOiJIUzI1NiIsImtpZCIgOiAiNDEzYjIyMzEtZmVlMi00ZWJiLWI3YjktNzU2YTcxNzNiZTc5In0.eyJqdGkiOiI3NGIyMzQxMi03MmRmLTRjNzMtYjlkNS0yNDM4NTQxNjcwZjkiLCJleHAiOjE1MzQyNzU4MzksIm5iZiI6MCwiaWF0IjoxNTM0MjM5ODM5LCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvamFlZ2VyIiwic3ViIjoiZDJjN2IxODQtODRiZi00MmUyLTg0Y2YtODNkYTg4OThhYjhjIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiMTM5YjUwMjgtOGQxOS00YWI0LWI2NTctYjA4ZmY4MTBhOGViIiwicmVzb3VyY2VfYWNjZXNzIjp7fSwic3RhdGVfY2hlY2tlciI6ImhNSkJQRm1UVVNUY1FqVmE3N2lWSk40U1hJcTI4UUwtbEZoWXZyR1NsWGMifQ.hNT-J7z3wV7DRobLgpDdQuNQXKDK0TvpF3deVf5evPo; Version=1; Path=/auth/realms/jaeger/; HttpOnly
Set-Cookie: KEYCLOAK_SESSION=jaeger/d2c7b184-84bf-42e2-84cf-83da8898ab8c/139b5028-8d19-4ab4-b657-b08ff810a8eb; Version=1; Expires=Tue, 14-Aug-2018 19:43:59 GMT; Max-Age=36000; Path=/auth/realms/jaeger/
Set-Cookie: KEYCLOAK_REMEMBER_ME=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/jaeger/; HttpOnly
P3P: CP="This is not a P3P policy!"
Location: http://localhost:8180/?state=79c00178-ca7c-4dfd-9c22-5007690486de&session_state=139b5028-8d19-4ab4-b657-b08ff810a8eb&code=eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..mHMPVn10n8vOWRnxu1SmtQ.vznK3zyDudPN9mXkfIHAUsG0TR_3YWSxif-uaMIMErjIPeqDEPVXbwC5GS30DENYkY6kDtY3aFChZ_4FJ3vquXQ_CiL_QcxEgn13UMYuqyGrnoEiq3l_F4jATUxNZ3XzrBThuWIKvzcpA3TyKCKwHhcvL1dJ2Z5OJscisIyrl426ug7JfK8YuCT90sJVrqBExQs5Mjx3Ws0EsE42rruHhQhi7nyOdu3khEWdMrEedGW2ZHIsEvBcYBrlK-CohJA-.psSj4X4yaqsGxcenlBSyHw
Content-Length: 0
Date: Tue, 14 Aug 2018 09:43:59 GMT
proxy.json
{
"target-url": "http://localhost:16686",
"bind-address": "0.0.0.0",
"http-port": "8080",
"applications": [
{
"base-path": "/",
"adapter-config": {
"realm": "jaeger",
"auth-server-url": "http://localhost:8080/auth",
"public-client": true,
"resource": "proxy-jaeger",
"ssl-required": "external",
"confidential-port": 0
},
"constraints": [
{
"pattern": "/*",
"roles-allowed": [
"application"
]
}
]
}
]
}
keycloak.json
{
"realm": "jaeger",
"auth-server-url": "http://localhost:8080/auth",
"ssl-required": "external",
"resource": "proxy-jaeger",
"public-client": true,
"confidential-port": 0
}
Check if your valid redirect URIs within Keycloak are correct. Add * if you want to make sure, that's not the problem; for security reasons it should be as exact as possible in production.
Your proxy.json constrains access to the role "application". Check if that role has been added within Keycloak to the Role Mapping.
Also, do you get an Error Message? If so, please post it.