I'm trying to integrate custom authentication service with micronaut security and to do this I've implemented my own AuthenticationProvider and that works fine for basic auth, however I also need to take care of authentication tokens passed in the request.
To do this I'm trying to implement my own AuthenticationFetcher and in the fetchAuthentication method I'm trying to get my custom authentication header and then authenticate the request.
#Override
public Publisher<Authentication> fetchAuthentication(HttpRequest<?> request) {
if (request.getHeaders().get(authConfiguration.getTokenHeader()) != null) {
The issue I'm having is that netty's request.getHeaders() doesn't return all headers that are being sent to the webservice (I confirmed from my browsers developer console)
GET /service/all HTTP/1.1
Accept: application/json, text/plain, */*
Cookie: m=2258:Z3Vlc3Q6Z3Vlc3Q%253D
Accept-Encoding: gzip, deflate
Host: localhost:4200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1 Safari/605.1.15
Accept-Language: pl-pl
Referer: http://localhost:4200/campaigns
Connection: keep-alive
X-Token: my.token.here
And here are my app settings
micronaut:
server:
netty:
maxHeaderSize: 1024
worker:
threads: 4
parent:
threads: 4
childOptions:
autoRead: true
application:
name: appName
Any feedback appreciated.
It was caused by cors config:
micronaut:
server:
cors:
enabled: true
After adding this my request header was removed in the filter chains.
Related
I'm running GenHTTP server that is setup to to have CORS permissive (so allow all):
var inline = Inline.Create();
inline.Add(CorsPolicy.Permissive());
For some reason the request still fails by CORS. For context http://localhost:55409 is the server and http://localhost:55309 is the client.
Options (preflight):
Request URL: http://localhost:55409/api/v1//metadata
Request Method: OPTIONS
Status Code: 204 No Content
Remote Address: [::1]:55409
Referrer Policy: strict-origin-when-cross-origin
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: *
Access-Control-Allow-Origin: http://localhost:55309
Access-Control-Expose-Headers: *
Access-Control-Max-Age: 86400
Connection: Keep-Alive
Content-Length: 0
Date: Mon, 13 Jun 2022 13:05:34 GMT
Server: GenHTTP/6.3.4.0
Vary: Origin
This returns 204 OK.
Get:
Request URL: http://localhost:55409/api/v1//metadata
Referrer Policy: strict-origin-when-cross-origin
Provisional headers are shown
Learn more
Accept: application/json, text/plain, */*
Authorization: Bearer <token>
Referer: http://localhost:55309/
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="102", "Google Chrome";v="102"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36
Returns CORS error
This also feels weird as similar requests without Authorization header return 200 OK. The options seem to be correct in that it allows everything. Why does it fail then?
Also note that this works with the other server (more proper server running .Net Web Api), so client is not to blame. I think I'm missing some crucial server setup
Turns out I needed to specifically configure it to allow Authorization header, as if * does not include it?
inline.Add(new CorsPolicyBuilder().Default(new OriginPolicy(null, new List<string>() { "authorization" }, null, AllowCredentials: true, 86400u)));
This is the answer, but I'll mark the other answer whoever can explain why * does not include Authorization as OPTIONS has returned this
Access-Control-Allow-Headers: *
so I assume that should allow Authorization header as well
Working on some code that that I inherited from a non-responsive initial developer. My ASP.NET and web.config are at best "dated", thus I'm turning to the community for some help. One of the first things I had to change is to force this website to operate in SSL (https:) as it deals with sensitive data. The program immediately stopped working and I had to make some undesirable changes to code that "already worked". And it still seems broken, and the changes won't make the client happy.
This is an ASP.NET project that seems hand-rolled.
Sending a POST command with some body text that (I think) is JSon setting additional parameters to the POST command such as: "indexID=8379fcd1-5083-4d1c-a6ee-5812f134a505".
As far as I can tell, this works as intended on non SSL (i.e. http: requests). However, when running in SSL (i.e. https: requests), it appears that the BODY (Json text) isn't getting decoded into the HttpContect.Current.Request parameters (which seems to be happening in http:).
However the post_data that I can read from the input stream has the JSon body text (as clear text?) with the parameters, which my 'fix' adds to the incoming HttpContect.Current.Request parameters as a combined dictionary.
[Here is the RAW command intercepted with Fiddler] POST https://vmdev-xpp/BuilderQC/Services/Data.svc/QueryGridResults?typename=ImportReadyForDownload HTTP/1.1 Host: vmdev-xpp User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0 Accept: application/json, text/javascript, /; q=0.01 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Content-Type: application/x-www-form-urlencoded X-Requested-With: XMLHttpRequest Content-Length: 378 Origin: https://vmdev-xpp Connection: keep-alive Referer: https://vmdev-xpp/BuilderQC/BREDFileManagement.aspx Cookie: ASP.NET_SessionId=ehi2ccsdmekvkgegmfh11n1v; .ASPXLMPTest=2226D5725FBC10FBCCD606108CE5A4E32990EEA8FF8A1864496F69874F116D7E1ABF48A8BFD05EE683FE3F456D4475E88A61B19B299CB557209129BD25E87AC38CECA5303C7E2035E64C1F5A4AD2605D8581181A9C7E48680371F83BC7A93D7A63D8748EA4761A608F424578C20127D01DE0E2FBFBD5F079575E86FD506925D541026B7C8713FDEFE108BCEADBFC1DA0 Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin
_search=true&nd=1629052554858&rows=40&page=1&sidx=&sord=asc&QC_ProjectID=14&FileReadyForDownload=1&filters=%7B%22fields%22%3A%5B%7B%22field%22%3A%22QC_ProjectID%22%2C+%22op%22%3A+%22cn%22%2C+%22value%22%3A%2214%22%7D%2C%7B%22field%22%3A%22FileReadyForDownload%22%2C+%22op%22%3A+%22cn%22%2C+%22value%22%3A%221%22%7D%5D%7D&indexID=8379fcd1-5083-4d1c-a6ee-5812f134a505&entity=false
[Here is the post_data I obtained from the input stream, I think that this being in clear-text is suspect] Post_data = _search=true&nd=1629052767566&rows=40&page=1&sidx=&sord=asc&QC_ProjectID=14&FileReadyForDownload=1&filters=%7B%22fields%22%3A%5B%7B%22field%22%3A%22FileName%22%2C+%22op%22%3A+%22cn%22%2C+%22value%22%3A%22th%22%7D%2C%7B%22field%22%3A%22QC_ProjectID%22%2C+%22op%22%3A+%22cn%22%2C+%22value%22%3A%2214%22%7D%2C%7B%22field%22%3A%22FileReadyForDownload%22%2C+%22op%22%3A+%22cn%22%2C+%22value%22%3A%221%22%7D%5D%7D&indexID=8379fcd1-5083-4d1c-a6ee-5812f134a505&entity=false&FileName=th
Here is the incoming HttpContext.Current.Request.Params.AllKeys, Notice the lacking "indexID" among other parameters
I deployed my express app on Firebase Functions with cors setting. However, on the browser, the below error printed on the console.
Access to fetch at 'https://....cloudfunctions.net/users/' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
On my code,
...
import * as cors from 'cors'
const app = express()
app.use(cors({ origin: true })) // Set CORS properly
app.use(helmet())
app.use(express.json())
app.use(express.urlencoded({ extended: true }))
app.use('/', router)
app.use(errorHandler)
export const users = functions
.region('asia-northeast3')
.https.onRequest(app)
I cannot find what is the problem. Even the official document recommends app.use(cors({ origin: true})). How can I solve this problem?
====EDIT====
My request looks like:
GET /baggle-318109/us-central1/auth/kakao HTTP/1.1
Host: localhost:5001
Connection: keep-alive
sec-ch-ua: "Chromium";v="92", " Not A;Brand";v="99", "Google Chrome";v="92"
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36
Accept: */*
Origin: http://localhost:3000
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: http://localhost:3000/
Accept-Encoding: gzip, deflate, br
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
If-None-Match: W/"d-vfAVvdILIkmIo67j2sc7s17+9M0"
You send a request from localhost:3000 to localhost:5001. So, basically you use different URLs (differing by port number) and that throws a CORS error, that is saying to you that
you have a different origin from the target
the target did not allow you to do so
The solution is simple: make the target allowing you to do this. Before you continue, read this: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors
You will need to have a Access-Control-Allow-Origin header in your response at localhost:5001. You could specify a wildcard of
Access-Control-Allow-Origin: *
to allow any origin to send a request. You may allow a single source, by putting the source as a value instead of *. Read more here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin
Changing the response headers and adding the Access-Control-Allow-Origin is a topic by itself and can be done differently for different servers. You will need to know what server you use for your project that's triggered when you request on localhost:5001 and to look up how can you add this header there.
I have a problem with recreating the headers, everything seem identical, but it just doesn't work. Need those headers to access Instagram API
I tried to use Charles to intercept a traffic from mobile device and it's working as expected, but I'm struggling to recreate the same headers.
URL is https://i.instagram.com/api/v1/feed/user/7499201770/reel_media/
Headers are
:method: GET
:scheme: https
:path: /api/v1/feed/user/7499201770/reel_media/
:authority: i.instagram.com
content-type: application/json
authority: i.instagram.com
accept: */*
path: /api/v1/feed/user/7499201770/reel_media/
accept-language: en-IN;q=1.0
accept-encoding: gzip;q=1.0, compress;q=0.5
content-length: 2
user-agent: Instagram 10.29.0 (iPhone7,2; iPhone OS 9_3_3; en_US; en-US; scale=2.00; 750x1334) AppleWebKit/420+
referer: https://www.instagram.com/
x-ig-capabilities: 3w==
cookie: ds_user_id=6742557571; sessionid=IGSCf716eb61bf2a6d41f...
I tried to use Postman in order to recreate this request, but every time I get the same error "Login required". How should I paste those headers? I can't understand that
It was the user-agent: Instagram 10.29.0 (iPhone7,2; iPhone OS 9_3_3; en_US; en-US; scale=2.00; 750x1334) AppleWebKit/420+ that I didn't copy
With user-agent it works, so HTTP headers will look like this in case someone writing an instagram story saver)
["Content-Type": "application/json",
"Accept-encoding": "gzip, deflate",
"User-agent": "Instagram 10.29.0 (iPhone7,2; iPhone OS 9_3_3; en_US; en-US; scale=2.00; 750x1334) AppleWebKit/420+",
"Cookie": "ds_user_id=67425...; sessionid=IGSCf716eb61b....]
This is a node webkit application that manages a bunch of webkit windows. Each webkit window uses signalR to connect to a MVC/webApi/signalR stack with no problems. Each window connects to 1-3 hubs over websockets. Everything works well.
My client wants to use SignalR inside the base node application that manages all the other windows. This is where things are getting 'interesting'...
So although the node app is running in a webkit environment it is served from the file system (header:origin=file://)
So i have started up signalR like (no JSONP as i'm targeting websockets)
app.Map("/signalr", map =>
{
map.UseCors(CorsOptions.AllowAll);
var hubConfiguration = new HubConfiguration();
map.RunSignalR(hubConfiguration);
});
So when i connect in the node app before the user logs into one of the windows spawned from Node, signalR connects over websockets fine, and i don't get any errors when they login(i.e. user has changed identity).
var connection = window.$.hubConnection("http://localhost");
connection.logging = true;
connection.start()
.done(function () { console.log('Now connected, connection ID=' + connection.id); })
.fail(function () { console.log('Could not connect'); });
the issue is i don't have the identity in the HubCallerConext serverside.
So if the user logs in first, then the node application has the cookies created in the other spawned window and this is where things get weird. SignalR fails to connect over websockets with the following error (from fiddler)
Unrecognized user identity. The user identity cannot change during an active SignalR connection.
Here is the negotiate call and then the failing call to connect (upgrade) over websockets.
I have a fiddler rule replacing Origin:file:// with localhost. just in case this was effecting it.
GET http://localhost/signalr/negotiate?clientProtocol=1.4&connectionToken=qs09pHGxr6x5fff1GJ%2FChWUnpSLX5ljV8FuS3h06P%2FhpS55cjNvh2uFHHTXukDI%2BK%2BcgsC6%2BWVJHba4xrkt6IVc2KwGIfm4eeyHrigNFRotjBYKb&connectionData=%5B%7B%22name%22%3A%22windowmanagementhub%22%7D%5D&_=1429572950768 HTTP/1.1
Host: localhost
Connection: keep-alive
Accept: text/plain, */*; q=0.01
X-DevTools-Emulate-Network-Conditions-Client-Id: 2E81759B-036D-4E92-ADF4-865AFBF59D2
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.76 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-us;q=0.8,en;q=0.6
Cookie: ASP.NET_SessionId=opyggkqxnudnuag5mtxy40ai; __APPLICATION_LANGUAGE=en-GB; __RequestVerificationToken=eoB...GHjTo1; .ASPXAUTH=6909...82ED0; WindowsAuthCookie.LoginName=userName
Origin: http://localhost
and response
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8
Expires: -1
Server: Microsoft-IIS/8.5
Access-Control-Allow-Origin: http://localhost
Access-Control-Allow-Credentials: true
X-Content-Type-Options: nosniff
Date: Mon, 20 Apr 2015 23:46:49 GMT
177
{"Url":"/signalr","ConnectionToken":"LwJz6Ev3+9C/NbKBqHkrI8KwYaz53qiBbzDJVlcse1qRXU3loCqOI68kUb4kpyk8gdQlkKRJ0wBrpb+VVtUMFtrtSQOEhGQE9ZNaMDBajyK2/Evz","ConnectionId":"68e7751b-aaee-4ed7-aa36-a2d1ab25107f","KeepAliveTimeout":20.0,"DisconnectTimeout":30.0,"ConnectionTimeout":110.0,"TryWebSockets":true,"ProtocolVersion":"1.4","TransportConnectTimeout":5.0,"LongPollDelay":0.0}
0
then the following connect headers, which is the request that gets the 403
GET http://localhost/signalr/connect?transport=webSockets&clientProtocol=1.4&connectionToken=LwJz6Ev3%2B9C%2FNbKBqHkrI8KwYaz53qiBbzDJVlcse1qRXU3loCqOI68kUb4kpyk8gdQlkKRJ0wBrpb%2BVVtUMFtrtSQOEhGQE9ZNaMDBajyK2%2FEvz&connectionData=%5B%7B%22name%22%3A%22windowmanagementhub%22%7D%5D&tid=0 HTTP/1.1
Host: localhost
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://localhost
Sec-WebSocket-Version: 13
User-Agent:
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-us;q=0.8,en;q=0.6
Sec-WebSocket-Key: HqfgeBw4svkTTpBK2CfaJA==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
and the 403 response
HTTP/1.1 403 Forbidden
Cache-Control: no-cache
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/html
Expires: -1
Server: Microsoft-IIS/8.5
Access-Control-Allow-Origin: http://localhost
Access-Control-Allow-Credentials: true
X-Content-Type-Options: nosniff
Date: Mon, 20 Apr 2015 23:46:49 GMT
61
Unrecognized user identity. The user identity cannot change during an active SignalR connection.
0
Here is the javascript error in the console (from jquery.signalR 2.1.2, different connection ids, tokens)
WebSocket connection to
'ws://localhost/signalr/connect?transport=webSockets&clientProtocol=1.4&connectionToken=xzGshRPvF1XvGnq2S2nDmGZ3TISMGEt01Au0z9J%2FAfMa2OtQUMW5XX5HgW0I4n2MK5UfGfpJ4%2Fl7OkiRpQlSIFrDkfy25WHScwpkubBsn5403%2Ba3&connectionData=%5B%7B%22name%22%3A%22windowmanagementhub%22%7D%2C%7B%22name%22%3A%22browserloghub%22%7D%5D&tid=1'
failed: Error during WebSocket handshake: Unexpected response code: 403
SignalR will then (correctly) fall back to SSE and connect successfully. I can see the Identity of the user serverside.
I would really like to understand why i can't connect over websockets when the user is authenticated. If i delay ALL windows from connecting to the server via signalR until the user is authenticated then i also see the same behavior.
any help or clues would be greatly appreciated.