Redirect URI wrong Protocol
Okay, getting further this time around. I almost could get in past
OIDC but homarr's auth is building my redirect_uri as http not https. I tried with / without NEXTAUTH_URL variable set (maybe dep at this point, but didnt make any diff). Authelia is obviously rejecting it, and i can't add http rules as they are insecure. It looks like the new version works with 256 PKCE too. I run homarr as a reverse proxied service in that authelia.
looks like it's created with the headers, which may explain it. https://github.com/homarr-labs/homarr/blob/3b7e6cc083220a0e3a0cf4f5243c073067ba5bc7/packages/auth/redirect.ts#L11C14-L11C31 ..
Edit.. : https://github.com/homarr-labs/homarr/blob/3b7e6cc083220a0e3a0cf4f5243c073067ba5bc7/packages/common/src/url.ts#L7
This works 100% fine in the old version.16 Replies
Thank you for submitting a support request.
Depending on the volume of requests, our team should get in contact with you shortly.
⚠️ Please include the following details in your post or we may reject your request without further comment: - Log (See https://homarr.dev/docs/community/faq#how-do-i-open-the-console--log) - Operating system (Unraid, TrueNAS, Ubuntu, ...) - Exact Homarr version (eg. 0.15.0, not latest) - Configuration (eg. docker-compose, screenshot or similar. Use ``your-text`` to format) - Other relevant information (eg. your devices, your browser, ...)
❓ Frequently Asked Questions | Homarr documentation
Can I install Homarr on a Raspberry Pi?
Tried to send send the headers as all lower case.. edit.. no dice. Maybe there should just be an option to override this? I'm also seeing
Partitioned cookie or storage access was provided to in my browser ... like process.env.force_http_proto || {proto} would fix this ... stuck here, & rolled back for nowDebian... docker,
beta branch tag... docker-compose... with AUTH_OIDC_ISSUER: https://auth.${DOMAIN_NAME} and all associated fields.. edit: verified the beta is the right version and the checker is wrong, maybe an actions issue thereNote for me: Test
req.nextUrl.protocol and req.connection.encryptedSince a OpenID/OAuth
redirectURI is invalid as HTTP, can you just replace baseUrl here with https if its http? https://github.com/homarr-labs/homarr/blob/3b7e6cc083220a0e3a0cf4f5243c073067ba5bc7/packages/auth/redirect.ts#L16
Then you're not relying on headers to determine this. FWIW, I am passing the X-FORWARDED-PROTO via SWAG to the homarr container, but as you know, it runs multiple websockets. Maybe the layering is throwing the variable off (or not being passed through)? If the internal homarr (nginx) webserver supported TLS that would also negate this issue 🙂
https://github.com/homarr-labs/homarr/blob/dev/nginx.conf#L24 also, not an expert on if homarr is implementing more overrides, but isnt the $scheme here going to resolve as http (never s) if it's coming from a internal http server with that fixed proxy_pass?
In the tests: also: https://github.com/homarr-labs/homarr/blob/b6dc38483d81ddbbebb9ea35c78bacff516a0e0b/packages/auth/test/redirect.spec.ts#L6 really not sure this should be supported given the methods of data transmission used in client_secret_post or pkce or the sha256 encryption to send the token clear. Authelia simply errors if yours is http.Hey, sorry for the silence in the last few days. I'm publishing a new image for you to try it out. In this it fallbacks to
https for oidc redirect_uri whenever the header is not set. It will be available in about 25 minutes, so you need to wait until then to test it out. the image tag will be oidc-redirect-fallback-https. I'll let you now again when it's ready
Okay the image would be readyOkay! Thank you will try shortly here and report / edit my result back. Thank you for your attention to this!
Same error unfortunately using the
oidc-redirect-fallback-https , the redirect_uri still produces a http link for me. I tried docker compose down homarr then pruned the image, then pulled it fresh, same issue.
Okay thank you for testing, I'll check if there is a better way
Okay you were right, sorry. It actually was an issue with the nginx configuration setting x-forwarded-proto from scheme which always is http as it seems like. I've updated this to the provided x-forwarded-proto. Image is on its way and will be available again in about 35 minutes. I tested it locally with the previous version (without nginx configuration changes) and adjusted configuration and it worked with azure ad app registrations
Okay image is updated and ready to test again
Worked
Yay 🙂
Thanks for your assistance, now I can play
Okay great then I'll create a pull request so we can put in into our next release
Says I have 4 boards, but when I click on it, it doesn't list any of them. Is this a known issue that's unrelated?
I'll probably just make a new one and hopefully that one shows up
I think my user is not an admin, which is curious because when it asked, I did correctly assign it to 'admin' which is name of my OIDC admin group claim as well
Going to start from zero and hopefully that helps
Yeah, board not found / you dont have access. On the import. This might be due to how OIDC works? I dont know. Now I'm trying from absolutely zero
ok, just broken for OIDC in general. The OIDC admin is not being assigned ever. Even starting from scratch doesnt create an admin user
It should create the admin group and if you write the group name correctly it should assign the oidc user to it
For me it also does not seem to work, let me check why
Okay nevermind during the onboarding we forgot to give it admin permission 😂 sorry
XD
Solution
Fixed in about 25 minutes in release
v1.0.0-beta.7okay! Thank you again. Looks like its working!
I'm gonna mark this solved so I dont get encouraged to keep the thread going because its good now 🙂 thx again
👍🏽