I was reading over cache-control request/response headers here.
Definition of Cache-Control: No-Store:
The no-store directive means browsers aren’t allowed to cache a response and must pull it from the server each time it’s requested. This setting is usually used for sensitive data, such as personal banking details.
Cloud Foundry UAA stores its public keys for JWT signature validation at https://uaa.my-domain.com/token_keys and it's cache-control response header contains no-store.
This makes no sense to me - they are public keys that do not require authorization to acquire. Additionally, there is an ETag response header that implies, according to the link referenced above, that a browser or client will be caching the response.
Related
I have two headless backend services: Saleor and Strapi, which provide with GraphQL API for e-commerce development. The problem was to find a service, which can stitch two( or more ) GraphQL schemas so that I can have access to them by one endpoint. Such service is StepZen. Normally when trying to fetch requests on StepZen you would have to do it with
{
"Authorization": "apikey <apikey>"
}
as a header. And it would also work. But when you have some fields in schemas you stitching which Require JWT authentication you need somehow to pass in Authorization header Bearer token. In StepZen there is an opportunity to forward headers, so theoretically I could use that to forward Authorization header to fields, because StepZen also provides JWT Authentication when making your request instead of using API-Key. And THAT is the main problem(failing to access StepZen with only Bearer Token).
As it stays in documentation I changed my config.yaml file accordingly:
deployment:
identity:
jwksendpoint: https://<MY-DOMAIN>/.well-known/jwks.json
access:
policies:
- type: Query
policyDefault:
condition: '?$jwt'
Unfortunately trying after this accessing the endpoint with the Bearer Token as the value of Authorization header like this:
{"Authorization" : "Bearer <token>"}
got me always the same 401 error from StepZen, NOT Saleor( Unauthorized: missing or not allowed ), which means that none of my requests reach its endpoint. I am totally lost, because I tried already all combinations from the StepZen docs of config.yaml file and none of that worked. I would be very happy if someone could explain me what the problem is.
I have a backend service configured as a subdirectory behind a reverse proxy. The backend has its own auth scheme, and it relies on the authorization header being formatted as
Bearer <JWT Token>
in order to validate a session. Unfortunately, the backend reveals what it is to any curious eyes, and doesn't keep any record of auth attempts/failures to filter with, for example, fail2ban.
I would like to hide the backend behind basic auth, so the page details are only loaded for authorized users, and so that I can monitor auth attempts/failures across all my backends with a simplified fail2ban filter.
The problem I'm encountering, is that in order for the client's requests to reach the backend, once it's secured behind basic auth, the Authorization header needs to be formatted as
Basic <base64-encoded username:pass pair>
The moment the client sets this header, though, the backend is unreachable. The backend and the client also have quite a bit of back-and-forth communication, and from what I can tell <UserToken> is dynamically generated for each login session.
I've tried
proxy_set_header Authorization <A statically generated and set JWT Token for testing>
In the location block of the backend. However, at some point in the transactions that result between client and backend, the Authorization header goes from
Basic (with backend asking for credentials)-> Bearer (backend is authenticated and loads a few resources until...) -> Basic (backend is now logged out and reauthenticating causes an infinite loop)
Essentially, as soon as the Authentication header is reset by the client to authenticate with basic auth, presumably for the client's next request, the backend becomes inaccessible. I would like a way to dynamically maintain two Authorization headers with nginx, if such a configuration is possible, and set the header appropriately according to where in the chain between client, proxy, and backend the request occurs.
I've also tried to experiment a little bit with a mapping like:
map $http_authorization $origin_auth {
"Bearer" $http_authorization;
}
and then adding this directive inside the server block:
add_header my-header $origin_auth always;
Just to see if I could store the header for retrieval on one of the client's future requests, or something... scrolling through dev tools though, to examine the header fields, "my-header" never assumes the value of the backend's expected authorization header.
I don't have enough experience with either the http protocol, or nginx, to know if the thing I want to accomplish is even possible, and I haven't found much help in other posts. I have tried throwing about 3 dozen hours of my life at the problem though, without any luck. Any help would be very welcome and appreciated.
I'm building a React app that allows users to login with Google and then connects to a webhook/3rd Party service in Realm. The service should only return data that the users own.
I've set up the OAuth 2 with Google and can get back access_token for a user and I then pass it in the header (I've also tried the URL params) to the webhook. But I get an error back saying:
400 "no authentication methods were specified" - "Invalid Parameter".
After much testing, I've identified that it must be a Realm issue - but I can't figure out what.
I've tried authenticating with Google in Postman and sending a request from there like this:
GET <incoming_webhook URL>
Request Headers
Authorization: Bearer <access_token>
User-Agent: PostmanRuntime/7.26.10
Accept: */*
Host: us-east-1.aws.webhooks.mongodb-realm.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
But I get the same error.
In Realm I have "Google" enabled as an authentication providers (and the authentication works just not the authorization through the webhook).
Per https://docs.mongodb.com/realm/services/configure/service-webhooks/#configure-user-authentication, you can choose email/password, an API key, or a custom JWT token. I don't know whether you can use google login directly to a webhook, but you're probably better off making a realm function instead.
Regarding the error no authentication methods were specified, you can specify the type of authentication method (using a custom JWT as an example) by either:
putting it in the header:
Header: jwtTokenString, Value: eyJhbGci.....
OR
by including it as part of the webhook body:
{
"jwtTokenString":"eyJhbGci...",
"mydata": "my data value"
}
If you try to use both methods, you get a multiple authentication methods used error. HTTP Bearer tokens in the header, etc, are useless here.
For an API Key, instead of jwtTokenString, use api-key; or email`password` for email\password authentication.
I found these methods of providing authenticating information really unintuitive and the documentation very unclear.
I am facing difficulties in overriding the list of HTTP Response headers listed below
X-Content-Type-Options (from 1 to nosniff)
X-Frame-Options (from SAMEORIGIN to deny)
Set-Cookie (add HttpOnly;Secure)
I have tried to put these values into the Listener's HTTP Response headers as well as utilizing the Header Removal and Header Injection in the API Manager policies but to no success in overriding to the intended values.
May I know how do override the HTTP Response headers? Kindly refer to the photo of the values that I have set.
API Policies
Header Removal
Header Injection
Listener's response header values in the mule project
Response header from the API call
These headers "X-Content-Type-Options", "X-Frame-Options" are injected by DLB, so not able to remove or modify at Mule app or policy level, unless not using DLB. MuleSoft has fixed it and should be available in their next release.
In the API Manager policies, use the Inbound Header Map instead of the Outbound Header Map for both header removal and injection.
I am experimenting with libcurl for a multipart upload to s3. My initiate multipart request looks like this
POST /my_new_file.mbi?uploads HTTP/1.1 Accept: / Host:
test_bucket.s3.amazonaws.com Date: Thu, 01 May 2014 13:35:17 GMT
Authorization: AWS4-HMAC-SHA256
Credential=XXXXXXX/20140501/us-east-1/s3/aws4_request,SignedHeaders=host,Signature=1a3fd6195040494dd95507455a3b1eefef40346485e3fdafbe6cc136192365a2
I get the following response
The provided 'x-amz-content-sha256' header must be a valid SHA256.
s3 documentation says we do not need any other headers for Initiate multipart upload call(POST). Have tried with various combinations of signed empty content, but no luck.
What am I missing here? Any suggestions here will be very helpful.
Thanks
I haven't used version 4 auth, yet, for multipart uploads (my code uses v2), but I did find this:
x-amz-content-sha256
When using signature version 4 to authenticate request, this header provides a hash of the request payload. For more information see Authenticating Requests by Using the Authorization Header (Compute Checksum of the Entire Payload Prior to Transmission) - Signature Version 4. When uploading object in chunks, you set the value to STREAMING-AWS4-HMAC-SHA256-PAYLOAD to indicate that the signature covers only headers and that there is no payload. For more information, see Authenticating Requests Using HTTP Authorization Header (Chunked Upload).
http://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonRequestHeaders.html
Obviously, chunked and multipart are not the same thing, but perhaps this value is also appropriate for a multipart upload request, or will generate a new and more helpful error message. The documentation seems unfortunately sparse in this case.
For Googlers who got this error:
Missing required header for this request: x-amz-content-sha256
While using awscli, what worked for me was setting the region correctly in the file ~/.aws/config (I'm using Ubuntu) to us-east-1. US only doesn't work nor does US Standard. The returned error doesn't really indicate that.
STREAMING-AWS4-HMAC-SHA256-PAYLOAD appears to no longer work. I was able to make it work by passing the SHA256 hash of the empty string, e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855