[GH-ISSUE #36] Adding Email Support & Seperate Users #18

Closed
opened 2026-05-07 00:17:29 +02:00 by BreizhHardware · 27 comments

Originally created by @jlengelbrecht on GitHub (Aug 14, 2024).
Original GitHub issue: https://github.com/glenndehaan/unifi-voucher-site/issues/36

Originally assigned to: @glenndehaan on GitHub.

Got this spun up in my homelab. Awesome work. Love this!

A few questions.
Would it be possible to add an option to send email via SMTP?
I would like to be able to email guests the tokens that get created.

What about additional users. Would it be possible to allow more then one user to have access? It be nice to see OIDC support or something similar in the future.

Originally created by @jlengelbrecht on GitHub (Aug 14, 2024). Original GitHub issue: https://github.com/glenndehaan/unifi-voucher-site/issues/36 Originally assigned to: @glenndehaan on GitHub. Got this spun up in my homelab. Awesome work. Love this! A few questions. Would it be possible to add an option to send email via SMTP? I would like to be able to email guests the tokens that get created. What about additional users. Would it be possible to allow more then one user to have access? It be nice to see OIDC support or something similar in the future.
BreizhHardware 2026-05-07 00:17:29 +02:00
Author
Owner

@glenndehaan commented on GitHub (Aug 15, 2024):

Hey thank you for the nice words, and good suggestions.

I can have a look into the email feature this weekend to see what is possible.
In terms of the OIDC I would need to have look since I don't want to make the application to complex and to heavy. There is already an option to disable the built-in auth, this could be used in combination with for example a proxy like: https://docs.goauthentik.io/docs/providers/proxy/

But I do get your point and this has also been asked for before, so I will have a look to see what is possible.

<!-- gh-comment-id:2290768861 --> @glenndehaan commented on GitHub (Aug 15, 2024): Hey thank you for the nice words, and good suggestions. I can have a look into the email feature this weekend to see what is possible. In terms of the OIDC I would need to have look since I don't want to make the application to complex and to heavy. There is already an option to disable the built-in auth, this could be used in combination with for example a proxy like: https://docs.goauthentik.io/docs/providers/proxy/ But I do get your point and this has also been asked for before, so I will have a look to see what is possible.
Author
Owner

@glenndehaan commented on GitHub (Aug 17, 2024):

Goodmorning,

I have just release version 2.7.3 that contains the mail functionality.
Please checkout the readme on how to configure it: https://github.com/glenndehaan/unifi-voucher-site?tab=readme-ov-file#email-functionality

In regards to the OIDC I need some more time to refactor the application to make that happen. I will keep this issue open to provide updates when I have more news.

<!-- gh-comment-id:2294849473 --> @glenndehaan commented on GitHub (Aug 17, 2024): Goodmorning, I have just release version 2.7.3 that contains the mail functionality. Please checkout the readme on how to configure it: https://github.com/glenndehaan/unifi-voucher-site?tab=readme-ov-file#email-functionality In regards to the OIDC I need some more time to refactor the application to make that happen. I will keep this issue open to provide updates when I have more news.
Author
Owner

@jlengelbrecht commented on GitHub (Aug 17, 2024):

Awesome! Thank you so much for taking the time to implement this. I will test this later tonight and will provide feedback.

<!-- gh-comment-id:2294975706 --> @jlengelbrecht commented on GitHub (Aug 17, 2024): Awesome! Thank you so much for taking the time to implement this. I will test this later tonight and will provide feedback.
Author
Owner

@jlengelbrecht commented on GitHub (Aug 18, 2024):

Tested this today. Email system works great. Thanks again.

<!-- gh-comment-id:2295132848 --> @jlengelbrecht commented on GitHub (Aug 18, 2024): Tested this today. Email system works great. Thanks again.
Author
Owner

@aroundmyroom commented on GitHub (Aug 18, 2024):

Maybe a comment to add that if you use TLS (Secure = True) to use port 465 otherwise use port 587?

If not than you will get errors about incorrect SSL.

I understand that this could be 'only for people who understand what they are doing' but otherwise it could give more questions or remarks that it does not work. (both is tested and working here).

<!-- gh-comment-id:2295243248 --> @aroundmyroom commented on GitHub (Aug 18, 2024): Maybe a comment to add that if you use TLS (Secure = True) to use port 465 otherwise use port 587? If not than you will get errors about incorrect SSL. I understand that this could be 'only for people who understand what they are doing' but otherwise it could give more questions or remarks that it does not work. (both is tested and working here).
Author
Owner

@glenndehaan commented on GitHub (Aug 19, 2024):

@aroundmyroom Yeah I get your point. The problem is that this isn't always the case. For example: My SMTP server provider utilizes port 25 but does require TLS (needs Secure = True). Thats why I kept both options open since not all providers are following the 'loose' standard

<!-- gh-comment-id:2295771759 --> @glenndehaan commented on GitHub (Aug 19, 2024): @aroundmyroom Yeah I get your point. The problem is that this isn't always the case. For example: My SMTP server provider utilizes port 25 but does require TLS (needs Secure = True). Thats why I kept both options open since not all providers are following the 'loose' standard
Author
Owner

@glenndehaan commented on GitHub (Aug 23, 2024):

Hi @jlengelbrecht,

I have some good news. After a lot of testing I have finally released version 3.1.0 that now has support for OIDC authentication.

Please have a look at the updated README on how to set it up: https://github.com/glenndehaan/unifi-voucher-site?tab=readme-ov-file#openid-connect-oidc-authentication

Also don't forget If you are still on v2 to read the migration documentation found here: https://github.com/glenndehaan/unifi-voucher-site?tab=readme-ov-file#migration-from-2x-to-3x

<!-- gh-comment-id:2307271653 --> @glenndehaan commented on GitHub (Aug 23, 2024): Hi @jlengelbrecht, I have some good news. After a lot of testing I have finally released version 3.1.0 that now has support for OIDC authentication. Please have a look at the updated README on how to set it up: https://github.com/glenndehaan/unifi-voucher-site?tab=readme-ov-file#openid-connect-oidc-authentication Also don't forget If you are still on v2 to read the migration documentation found here: https://github.com/glenndehaan/unifi-voucher-site?tab=readme-ov-file#migration-from-2x-to-3x
Author
Owner

@jlengelbrecht commented on GitHub (Aug 25, 2024):

Hi @glenndehaan started testing this but seem to be running into some issues. As I mentioned in my other post I use Unifi's Identity Enterprise as my IDP. From what I can tell implicit flow should be supported.

What does the Redirect url need to be set to in the IDP? I originally thought it would be https://your-domain.com/vouchers as this is the url you normally land on after signing in but this does not seem to be the case.

I have tried using https://your-domain.com/callback/oidc, https://your-domain.com and a few other iterations but I cant seem to get it to authenticate. Regardless of what i enter for the Redirect URL I get a ui.com/portal/fail-info?errorCode=E_U_APP_OIDC_NOT_MATCH_REDIRECT_URL error.

I followed the instructions and updated the values that were included in the upgrade guide but still can't seem to get OIDC sign in to work. Any guidance you could give me as to what I might be doing wrong is much appreciated.

Container logs

   __  __      _ _______    _    __                 __             
  / / / /___  (_) ____(_)  | |  / /___  __  _______/ /_  ___  _____
 / / / / __ \/ / /_  / /   | | / / __ \/ / / / ___/ __ \/ _ \/ ___/
/ /_/ / / / / / __/ / /    | |/ / /_/ / /_/ / /__/ / / /  __/ /    
\____/_/ /_/_/_/   /_/     |___/\____/\__,_/\___/_/ /_/\___/_/     
                           UniFi Voucher                           
                         By: Glenn de Haan                         
         https://github.com/glenndehaan/unifi-voucher-site         
2024-08-25 03:46:37.854 INFO  [Version] 2024.08.23.14.42
2024-08-25 03:46:37.855 INFO  [Service][Web] Enabled!
2024-08-25 03:46:37.856 INFO  [Service][Api] Disabled!
2024-08-25 03:46:37.856 INFO  [VoucherType] Loaded the following types:
2024-08-25 03:46:37.858 INFO  [VoucherType][0] 1 day, multi-use, upload bandwidth limit: 25000 kb/s, download bandwidth limit: 25000 kb/s, quota limit: 2048 mb
2024-08-25 03:46:37.858 INFO  [VoucherType][1] 3 days, multi-use, upload bandwidth limit: 25000 kb/s, download bandwidth limit: 25000 kb/s, quota limit: 2048 mb
2024-08-25 03:46:37.859 INFO  [VoucherType][2] 7 days, multi-use, upload bandwidth limit: 25000 kb/s, download bandwidth limit: 25000 kb/s, quota limit: 2048 mb
2024-08-25 03:46:37.859 INFO  [Auth] Enabled!
2024-08-25 03:46:37.860 INFO  [Email] Enabled! SMTP Server: smtp.myserver.com:423
2024-08-25 03:46:37.861 INFO  [UniFi] Using Controller on: 10.20.66.1:443 (Site ID: default)
2024-08-25 03:46:37.867 INFO  [OIDC] Set secret: 81b6f4e8e007970b7e40531879dd961bf4df352e
2024-08-25 03:46:37.961 INFO  [OIDC] Issuer: https://my-domain.ui.com/gw/idp/api/v1/public/oauth/super-secret-token/.well-known/openid-configuration, Client: my-client-id
2024-08-25 03:46:37.976 INFO  [App] Running on: 0.0.0.0:3000
2024-08-25 03:46:37.977 INFO  [Cache] Requesting UniFi Vouchers...
2024-08-25 03:46:38.582 INFO  [UniFi] Login successful!
2024-08-25 03:46:38.633 INFO  [UniFi] Found 2 voucher(s)
2024-08-25 03:46:38.633 INFO  [Cache] Saved 2 voucher(s)
2024-08-25 03:46:38.633 INFO  [Cache] Requesting UniFi Guests...
2024-08-25 03:46:38.670 INFO  [UniFi] Found 5 guest(s)
2024-08-25 03:46:38.670 INFO  [Cache] Saved 5 guest(s)
2024-08-25 04:01:38.672 INFO  [Auto Sync] Starting Sync...
2024-08-25 04:01:38.673 INFO  [Cache] Requesting UniFi Vouchers...
2024-08-25 04:01:38.776 INFO  [UniFi] Found 2 voucher(s)
2024-08-25 04:01:38.776 INFO  [Cache] Saved 2 voucher(s)
2024-08-25 04:01:38.777 INFO  [Cache] Requesting UniFi Guests...
2024-08-25 04:01:38.818 INFO  [UniFi] Found 5 guest(s)
2024-08-25 04:01:38.818 INFO  [Cache] Saved 5 guest(s)
2024-08-25 04:16:38.672 INFO  [Auto Sync] Starting Sync...
2024-08-25 04:16:38.673 INFO  [Cache] Requesting UniFi Vouchers...
2024-08-25 04:16:38.751 INFO  [UniFi] Found 2 voucher(s)
2024-08-25 04:16:38.751 INFO  [Cache] Saved 2 voucher(s)
2024-08-25 04:16:38.751 INFO  [Cache] Requesting UniFi Guests...
2024-08-25 04:16:38.786 INFO  [UniFi] Found 5 guest(s)
2024-08-25 04:16:38.787 INFO  [Cache] Saved 5 guest(s)

modified-screenshot1
modified-screenshot2
modified-screenshot3

<!-- gh-comment-id:2308655556 --> @jlengelbrecht commented on GitHub (Aug 25, 2024): Hi @glenndehaan started testing this but seem to be running into some issues. As I mentioned in my other post I use Unifi's Identity Enterprise as my IDP. From what I can tell implicit flow should be supported. What does the Redirect url need to be set to in the IDP? I originally thought it would be `https://your-domain.com/vouchers` as this is the url you normally land on after signing in but this does not seem to be the case. I have tried using `https://your-domain.com/callback/oidc`, `https://your-domain.com` and a few other iterations but I cant seem to get it to authenticate. Regardless of what i enter for the Redirect URL I get a `ui.com/portal/fail-info?errorCode=E_U_APP_OIDC_NOT_MATCH_REDIRECT_URL` error. I followed the instructions and updated the values that were included in the upgrade guide but still can't seem to get OIDC sign in to work. Any guidance you could give me as to what I might be doing wrong is much appreciated. # Container logs ``` __ __ _ _______ _ __ __ / / / /___ (_) ____(_) | | / /___ __ _______/ /_ ___ _____ / / / / __ \/ / /_ / / | | / / __ \/ / / / ___/ __ \/ _ \/ ___/ / /_/ / / / / / __/ / / | |/ / /_/ / /_/ / /__/ / / / __/ / \____/_/ /_/_/_/ /_/ |___/\____/\__,_/\___/_/ /_/\___/_/ UniFi Voucher By: Glenn de Haan https://github.com/glenndehaan/unifi-voucher-site 2024-08-25 03:46:37.854 INFO [Version] 2024.08.23.14.42 2024-08-25 03:46:37.855 INFO [Service][Web] Enabled! 2024-08-25 03:46:37.856 INFO [Service][Api] Disabled! 2024-08-25 03:46:37.856 INFO [VoucherType] Loaded the following types: 2024-08-25 03:46:37.858 INFO [VoucherType][0] 1 day, multi-use, upload bandwidth limit: 25000 kb/s, download bandwidth limit: 25000 kb/s, quota limit: 2048 mb 2024-08-25 03:46:37.858 INFO [VoucherType][1] 3 days, multi-use, upload bandwidth limit: 25000 kb/s, download bandwidth limit: 25000 kb/s, quota limit: 2048 mb 2024-08-25 03:46:37.859 INFO [VoucherType][2] 7 days, multi-use, upload bandwidth limit: 25000 kb/s, download bandwidth limit: 25000 kb/s, quota limit: 2048 mb 2024-08-25 03:46:37.859 INFO [Auth] Enabled! 2024-08-25 03:46:37.860 INFO [Email] Enabled! SMTP Server: smtp.myserver.com:423 2024-08-25 03:46:37.861 INFO [UniFi] Using Controller on: 10.20.66.1:443 (Site ID: default) 2024-08-25 03:46:37.867 INFO [OIDC] Set secret: 81b6f4e8e007970b7e40531879dd961bf4df352e 2024-08-25 03:46:37.961 INFO [OIDC] Issuer: https://my-domain.ui.com/gw/idp/api/v1/public/oauth/super-secret-token/.well-known/openid-configuration, Client: my-client-id 2024-08-25 03:46:37.976 INFO [App] Running on: 0.0.0.0:3000 2024-08-25 03:46:37.977 INFO [Cache] Requesting UniFi Vouchers... 2024-08-25 03:46:38.582 INFO [UniFi] Login successful! 2024-08-25 03:46:38.633 INFO [UniFi] Found 2 voucher(s) 2024-08-25 03:46:38.633 INFO [Cache] Saved 2 voucher(s) 2024-08-25 03:46:38.633 INFO [Cache] Requesting UniFi Guests... 2024-08-25 03:46:38.670 INFO [UniFi] Found 5 guest(s) 2024-08-25 03:46:38.670 INFO [Cache] Saved 5 guest(s) 2024-08-25 04:01:38.672 INFO [Auto Sync] Starting Sync... 2024-08-25 04:01:38.673 INFO [Cache] Requesting UniFi Vouchers... 2024-08-25 04:01:38.776 INFO [UniFi] Found 2 voucher(s) 2024-08-25 04:01:38.776 INFO [Cache] Saved 2 voucher(s) 2024-08-25 04:01:38.777 INFO [Cache] Requesting UniFi Guests... 2024-08-25 04:01:38.818 INFO [UniFi] Found 5 guest(s) 2024-08-25 04:01:38.818 INFO [Cache] Saved 5 guest(s) 2024-08-25 04:16:38.672 INFO [Auto Sync] Starting Sync... 2024-08-25 04:16:38.673 INFO [Cache] Requesting UniFi Vouchers... 2024-08-25 04:16:38.751 INFO [UniFi] Found 2 voucher(s) 2024-08-25 04:16:38.751 INFO [Cache] Saved 2 voucher(s) 2024-08-25 04:16:38.751 INFO [Cache] Requesting UniFi Guests... 2024-08-25 04:16:38.786 INFO [UniFi] Found 5 guest(s) 2024-08-25 04:16:38.787 INFO [Cache] Saved 5 guest(s) ``` ![modified-screenshot1](https://github.com/user-attachments/assets/e727b840-d57b-47df-a918-86e3561d35e2) ![modified-screenshot2](https://github.com/user-attachments/assets/07398cf5-a679-4e34-b97a-914d567762d8) ![modified-screenshot3](https://github.com/user-attachments/assets/57efcd8d-9e8b-4eca-9e92-f95b1a90948a)
Author
Owner

@glenndehaan commented on GitHub (Aug 25, 2024):

Hi @jlengelbrecht,

Wow I didn't know UID could act as an OIDC client. What I did within Keycloak and Authentik is set the url as: https://your-domain.com/*

However the direct url should be https://your-domain.com/callback
I hope this helps you

<!-- gh-comment-id:2308687985 --> @glenndehaan commented on GitHub (Aug 25, 2024): Hi @jlengelbrecht, Wow I didn't know UID could act as an OIDC client. What I did within Keycloak and Authentik is set the url as: https://your-domain.com/* However the direct url should be https://your-domain.com/callback I hope this helps you
Author
Owner

@jlengelbrecht commented on GitHub (Aug 25, 2024):

@glenndehaan Yeah UID Enterprise has a good selection SSO options. It also supports SAML auth.

So i updated the Sign-In Redirect URL to https://mydomain.com/callback and the Initiate Sign-In URI to https://mydomain.com/login the container logs seem to indicate that the app isn't getting the right information from the IDP.

Not sure what I am doing wrong.

Container logs

BadRequestError: state missing from the response

    at ResponseContext.callback (/app/node_modules/express-openid-connect/lib/context.js:366:15)

    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

The app now lands on a Bad Request page but the URL seems correct.

https://guestwif.mydomain.com/callback#access_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjA4ODcxNmJjYmMwMmQxMWZhNDc5YmI4NTA1MDk0NjU1NGE3NDQ3OTMifQ.eyJpc3MiOiJodHRwczovL2hvbWVsYWItMC51aS5jb20vZ3cvaWRwL2FwaS92MS9wdWJsaWMvb2F1dGgvMjQxZTAwNGEtZjRmMy00MTBhLTg5YTQtZDUzMzE3ZGU5MzExIiwic3ViIjoie1widXNlcl9pZFwiOlwiM2Y4NjQ3ZjMtMzkzYy00Mjc0LTlkMjItMzNmZTc5NWQ0OTBlXCIsXCJhcHBfaWRcIjpcIjI0MWUwMDRhLWY0ZjMtNDEwYS04OWE0LWQ1MzMxN2RlOTMxMVwifSIsImF1ZCI6WyJseDJrMjV5bWx3N3dxbDJyeDNpdXdzcXpvIl0sImV4cCI6MTcyNDYyNDA3MSwiaWF0IjoxNzI0NjIwNDcxLCJub25jZSI6ImNsUUw4MGx3cGRWLVlXTXRuZzU3cmZDZmZKbHI0eXJ4QjhiMjlCaE82NWsiLCJhdF9oYXNoIjoiUU1ZT21fSm1FY2JqT3FtUTFuVVRDUSIsImVtYWlsIjoiamxlbmdlbGJyZWNodDk2QGdtYWlsLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJmZWRlcmF0ZWRfY2xhaW1zIjp7ImNvbXBhbnlfaWQiOiI2MjYzOTBmZS05MDgxLTQ4MTMtYjc1Yi0xMmRiYjJkNTJhZGQiLCJhcHBfaWQiOiIyNDFlMDA0YS1mNGYzLTQxMGEtODlhNC1kNTMzMTdkZTkzMTEiLCJ1c2VyX2lkIjoiM2Y4NjQ3ZjMtMzkzYy00Mjc0LTlkMjItMzNmZTc5NWQ0OTBlIiwiY2xpZW50X2lkIjoibHgyazI1eW1sdzd3cWwycngzaXV3c3F6byJ9LCJmYW1pbHlfbmFtZSI6Ikpvc2giLCJnaXZlbl9uYW1lIjoiRW5nZWxicmVjaHQifQ.GUL2ZIOHpH_fie9R3Dp6FUrGGFE2mk7cLq-KXBVo1GLUnAzC-M7la4P-BDfsPnNGgbWnBS7tUItUrxgHDR7CdDG0TZJihJtN6O41Yrb1uA-DuBUBNHxh74HUpP5mZWX5JcRd8R6jh5Y4RzqQB88McDX0hAaJUcGhzyB6R8K3GRvKpgohWVtyHI9jozMhhQeTJZsK8gbWxqLrPvLzTCDO428w5MojM-IW2MdZ0Psh9vJcJjMNcqaDFN6-jC_1z2lGmInZtKlvytB7gveY9Of2WLLJJgKzc-a-OmCGBlcDS2REEBZyXs5mJ9-xm3GCik6qVYgnh_eg5EJi1hT1FK2o7A&expires_in=3599&id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjA4ODcxNmJjYmMwM...SOME..REALLY...LONG..TOKEN&state=eyJyZXR1cm5UbyI6Imh0dHBzOi8vZ3Vlc3R3aWZpLW1pbGt5d2F5LmRhdGEtaGFjay5uZXQifQ&token_type=bearer
<!-- gh-comment-id:2308997762 --> @jlengelbrecht commented on GitHub (Aug 25, 2024): @glenndehaan Yeah UID Enterprise has a good selection SSO options. It also supports SAML auth. So i updated the Sign-In Redirect URL to `https://mydomain.com/callback` and the Initiate Sign-In URI to `https://mydomain.com/login` the container logs seem to indicate that the app isn't getting the right information from the IDP. Not sure what I am doing wrong. # Container logs ``` BadRequestError: state missing from the response at ResponseContext.callback (/app/node_modules/express-openid-connect/lib/context.js:366:15) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) ``` The app now lands on a Bad Request page but the URL seems correct. ``` https://guestwif.mydomain.com/callback#access_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjA4ODcxNmJjYmMwMmQxMWZhNDc5YmI4NTA1MDk0NjU1NGE3NDQ3OTMifQ.eyJpc3MiOiJodHRwczovL2hvbWVsYWItMC51aS5jb20vZ3cvaWRwL2FwaS92MS9wdWJsaWMvb2F1dGgvMjQxZTAwNGEtZjRmMy00MTBhLTg5YTQtZDUzMzE3ZGU5MzExIiwic3ViIjoie1widXNlcl9pZFwiOlwiM2Y4NjQ3ZjMtMzkzYy00Mjc0LTlkMjItMzNmZTc5NWQ0OTBlXCIsXCJhcHBfaWRcIjpcIjI0MWUwMDRhLWY0ZjMtNDEwYS04OWE0LWQ1MzMxN2RlOTMxMVwifSIsImF1ZCI6WyJseDJrMjV5bWx3N3dxbDJyeDNpdXdzcXpvIl0sImV4cCI6MTcyNDYyNDA3MSwiaWF0IjoxNzI0NjIwNDcxLCJub25jZSI6ImNsUUw4MGx3cGRWLVlXTXRuZzU3cmZDZmZKbHI0eXJ4QjhiMjlCaE82NWsiLCJhdF9oYXNoIjoiUU1ZT21fSm1FY2JqT3FtUTFuVVRDUSIsImVtYWlsIjoiamxlbmdlbGJyZWNodDk2QGdtYWlsLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJmZWRlcmF0ZWRfY2xhaW1zIjp7ImNvbXBhbnlfaWQiOiI2MjYzOTBmZS05MDgxLTQ4MTMtYjc1Yi0xMmRiYjJkNTJhZGQiLCJhcHBfaWQiOiIyNDFlMDA0YS1mNGYzLTQxMGEtODlhNC1kNTMzMTdkZTkzMTEiLCJ1c2VyX2lkIjoiM2Y4NjQ3ZjMtMzkzYy00Mjc0LTlkMjItMzNmZTc5NWQ0OTBlIiwiY2xpZW50X2lkIjoibHgyazI1eW1sdzd3cWwycngzaXV3c3F6byJ9LCJmYW1pbHlfbmFtZSI6Ikpvc2giLCJnaXZlbl9uYW1lIjoiRW5nZWxicmVjaHQifQ.GUL2ZIOHpH_fie9R3Dp6FUrGGFE2mk7cLq-KXBVo1GLUnAzC-M7la4P-BDfsPnNGgbWnBS7tUItUrxgHDR7CdDG0TZJihJtN6O41Yrb1uA-DuBUBNHxh74HUpP5mZWX5JcRd8R6jh5Y4RzqQB88McDX0hAaJUcGhzyB6R8K3GRvKpgohWVtyHI9jozMhhQeTJZsK8gbWxqLrPvLzTCDO428w5MojM-IW2MdZ0Psh9vJcJjMNcqaDFN6-jC_1z2lGmInZtKlvytB7gveY9Of2WLLJJgKzc-a-OmCGBlcDS2REEBZyXs5mJ9-xm3GCik6qVYgnh_eg5EJi1hT1FK2o7A&expires_in=3599&id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjA4ODcxNmJjYmMwM...SOME..REALLY...LONG..TOKEN&state=eyJyZXR1cm5UbyI6Imh0dHBzOi8vZ3Vlc3R3aWZpLW1pbGt5d2F5LmRhdGEtaGFjay5uZXQifQ&token_type=bearer ```
Author
Owner

@glenndehaan commented on GitHub (Aug 25, 2024):

I have only seen this error once and that had to due with me being silly and restarting the service in between logins. This causes the secret to reset and the cookie to fail. But 3 things seem off here:

  1. You mention: and the Initiate Sign-In URI to https://mydomain.com/login, I have not set this up in both Keycloak and Authentik. And I want to understand the flow you are now trying. Are you logging in via UID or via the app itself. The reason I ask has to do with the cookie I mentioned earlyer, that cookie contains the state and if you now are trying to do a sort of silence sign in via UID I think that won't work.
  2. Is your app behind a proxy that has a valid SSL certificate? Since UID is hosted on https your app also must be due to the Strict cookie
  3. The callback URL seems incorrect to me. It sends the data as a GET and not a POST with form data. Here is the example response seen from my local instance that is redirected from my Keycloak instance (Are you sure the Implicit flow is enabled for this client?)
Scherm­afbeelding 2024-08-25 om 23 42 38 Scherm­afbeelding 2024-08-25 om 23 42 47
<!-- gh-comment-id:2309006314 --> @glenndehaan commented on GitHub (Aug 25, 2024): I have only seen this error once and that had to due with me being silly and restarting the service in between logins. This causes the secret to reset and the cookie to fail. But 3 things seem off here: 1. You mention: `and the Initiate Sign-In URI to https://mydomain.com/login`, I have not set this up in both Keycloak and Authentik. And I want to understand the flow you are now trying. Are you logging in via UID or via the app itself. The reason I ask has to do with the cookie I mentioned earlyer, that cookie contains the `state` and if you now are trying to do a sort of silence sign in via UID I think that won't work. 2. Is your app behind a proxy that has a valid SSL certificate? Since UID is hosted on https your app also must be due to the Strict cookie 3. The callback URL seems incorrect to me. It sends the data as a GET and not a POST with form data. Here is the example response seen from my local instance that is redirected from my Keycloak instance (Are you sure the Implicit flow is enabled for this client?) <img width="806" alt="Scherm­afbeelding 2024-08-25 om 23 42 38" src="https://github.com/user-attachments/assets/004f75b7-6b47-4d96-900e-7073b1482c93"> <img width="803" alt="Scherm­afbeelding 2024-08-25 om 23 42 47" src="https://github.com/user-attachments/assets/1c33294f-64fb-49de-a8e1-f5e17a177a3a">
Author
Owner

@jlengelbrecht commented on GitHub (Aug 25, 2024):

@glenndehaan So there is no explicit option to set a flow type in UID you can select between OIDC, SAML, or a Shortcut. When you add an app in UID you are given the following options. See screenshot below. It is required that a Initiate Sign-In URI and Sign-In Redirect URL are set in order to use OIDC.

I typically access the app via homepage which is outside of UID but I have users using the UID app and accessing the voucher site via UID's apps section. Currently the voucher site is setup as a Shortcut that points at the DNS entry from traefik. From there sign in via password.I have seperate app setup to test OIDC for the voucher site. If i access the app via homepage you are redirected to sign into UID if you have not signed in within the past 4 hours.From there UID redirects you to the app. If you are using UID to access the app you are automatically redirected as no sign in is required as you are already authenticated into UID.

I use wildcard certificates to get SSL certs for my self hosted apps.
Traefik is setup to point at my domain on cloudflare and retrieves wildcard certs from letsencrypt. I don't make any physical changes to apps or containers themself for SSL. Traefik manages all my SSL encryption to my apps.

2024-08-25-182754_hyprshot
2024-08-25-182835_hyprshot
edit1
edit2
2024-08-25-184613_hyprshot
edit3

<!-- gh-comment-id:2309033338 --> @jlengelbrecht commented on GitHub (Aug 25, 2024): @glenndehaan So there is no explicit option to set a flow type in UID you can select between OIDC, SAML, or a Shortcut. When you add an app in UID you are given the following options. See screenshot below. It is required that a `Initiate Sign-In URI` and `Sign-In Redirect URL` are set in order to use OIDC. I typically access the app via homepage which is outside of UID but I have users using the UID app and accessing the voucher site via UID's apps section. Currently the voucher site is setup as a Shortcut that points at the DNS entry from traefik. From there sign in via password.I have seperate app setup to test OIDC for the voucher site. If i access the app via homepage you are redirected to sign into UID if you have not signed in within the past 4 hours.From there UID redirects you to the app. If you are using UID to access the app you are automatically redirected as no sign in is required as you are already authenticated into UID. I use wildcard certificates to get SSL certs for my self hosted apps. Traefik is setup to point at my domain on cloudflare and retrieves wildcard certs from letsencrypt. I don't make any physical changes to apps or containers themself for SSL. Traefik manages all my SSL encryption to my apps. ![2024-08-25-182754_hyprshot](https://github.com/user-attachments/assets/abd90635-026b-405e-ac18-ff3114e03a48) ![2024-08-25-182835_hyprshot](https://github.com/user-attachments/assets/8b5eeec7-8e2b-40e5-aeb0-4ae319252f59) ![edit1](https://github.com/user-attachments/assets/15e96b3e-b49f-4b69-a17d-0b36574858d5) ![edit2](https://github.com/user-attachments/assets/b01018c9-0a4d-4efc-92e9-2925db77a72b) ![2024-08-25-184613_hyprshot](https://github.com/user-attachments/assets/ebff2253-6ea6-4a09-960f-14a99aee7314) ![edit3](https://github.com/user-attachments/assets/0ec4b58f-4086-479b-8663-c8beef732b05)
Author
Owner

@glenndehaan commented on GitHub (Aug 26, 2024):

After going through everything you send I think I see the issue. Since they are giving you a Client Secret within UID my guess is they only support Confidential Standard Flow clients. I think I should be able to refactor the client a bit to make that work. One thing I want to make sure is the following, if you open up the .well-known/openid-configuration within you browser can you check the following sections: grant_types_supported, response_types_supported. The output should look something like this:

Scherm­afbeelding 2024-08-26 om 08 18 20

My guess is that your output won't contain: implicit and id_token but will contain: authorization_code and code. If that is the case then I should be able to replicate some things locally. If not then we might have to see if we can schedule some sort of call to debug it on the fly.

<!-- gh-comment-id:2309421349 --> @glenndehaan commented on GitHub (Aug 26, 2024): After going through everything you send I think I see the issue. Since they are giving you a Client Secret within UID my guess is they only support Confidential Standard Flow clients. I think I should be able to refactor the client a bit to make that work. One thing I want to make sure is the following, if you open up the `.well-known/openid-configuration` within you browser can you check the following sections: `grant_types_supported`, `response_types_supported`. The output should look something like this: <img width="894" alt="Scherm­afbeelding 2024-08-26 om 08 18 20" src="https://github.com/user-attachments/assets/81570de6-2ed6-4ba1-84ed-e50f1fd3d21e"> My guess is that your output won't contain: `implicit` and `id_token` but will contain: `authorization_code` and `code`. If that is the case then I should be able to replicate some things locally. If not then we might have to see if we can schedule some sort of call to debug it on the fly.
Author
Owner

@glenndehaan commented on GitHub (Aug 26, 2024):

@jlengelbrecht I have just released version 3.3.0. This option now has support for the confidential flow that I think UID needs. Ensure the following environment variables are set:

AUTH_OIDC_CLIENT_TYPE=confidential
AUTH_OIDC_CLIENT_SECRET=

AUTH_OIDC_CLIENT_SECRET should contain the secret given by UID

The full guide can be found here: https://github.com/glenndehaan/unifi-voucher-site#configuration-2

<!-- gh-comment-id:2310733157 --> @glenndehaan commented on GitHub (Aug 26, 2024): @jlengelbrecht I have just released version 3.3.0. This option now has support for the confidential flow that I think UID needs. Ensure the following environment variables are set: ``` AUTH_OIDC_CLIENT_TYPE=confidential AUTH_OIDC_CLIENT_SECRET= ``` `AUTH_OIDC_CLIENT_SECRET` should contain the secret given by UID The full guide can be found here: https://github.com/glenndehaan/unifi-voucher-site#configuration-2
Author
Owner

@jlengelbrecht commented on GitHub (Aug 26, 2024):

After going through everything you send I think I see the issue. Since they are giving you a Client Secret within UID my guess is they only support Confidential Standard Flow clients. I think I should be able to refactor the client a bit to make that work. One thing I want to make sure is the following, if you open up the .well-known/openid-configuration within you browser can you check the following sections: grant_types_supported, response_types_supported. The output should look something like this:
Scherm­afbeelding 2024-08-26 om 08 18 20

My guess is that your output won't contain: implicit and id_token but will contain: authorization_code and code. If that is the case then I should be able to replicate some things locally. If not then we might have to see if we can schedule some sort of call to debug it on the fly.

sorry for the delay. My proxy broke have been trying to figure out why acme can't get new certs. Here is the screenshot of the well-known/openid-configuration I think your right UID doesn't seem to use implicit flow.

edit4

<!-- gh-comment-id:2311146737 --> @jlengelbrecht commented on GitHub (Aug 26, 2024): > After going through everything you send I think I see the issue. Since they are giving you a Client Secret within UID my guess is they only support Confidential Standard Flow clients. I think I should be able to refactor the client a bit to make that work. One thing I want to make sure is the following, if you open up the `.well-known/openid-configuration` within you browser can you check the following sections: `grant_types_supported`, `response_types_supported`. The output should look something like this: > <img alt="Scherm­afbeelding 2024-08-26 om 08 18 20" width="894" src="https://private-user-images.githubusercontent.com/7496187/361328779-81570de6-2ed6-4ba1-84ed-e50f1fd3d21e.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQ3MDg0MzgsIm5iZiI6MTcyNDcwODEzOCwicGF0aCI6Ii83NDk2MTg3LzM2MTMyODc3OS04MTU3MGRlNi0yZWQ2LTRiYTEtODRlZC1lNTBmMWZkM2QyMWUucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDgyNiUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA4MjZUMjEzNTM4WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ODliYTQ5NWQyMWVmMWE0NzhmNDhiYTg1YzgwODU2YmQ2ZGRiOTQwMDM3OThjNmUzZTk3YzRjZjlmMGNmNzg2OCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.x4qOkljXb5Mzp41opZpNefpk4wmjpm36m-mcSL9xyXw"> > > My guess is that your output won't contain: `implicit` and `id_token` but will contain: `authorization_code` and `code`. If that is the case then I should be able to replicate some things locally. If not then we might have to see if we can schedule some sort of call to debug it on the fly. sorry for the delay. My proxy broke have been trying to figure out why acme can't get new certs. Here is the screenshot of the `well-known/openid-configuration` I think your right UID doesn't seem to use implicit flow. ![edit4](https://github.com/user-attachments/assets/867a256e-59f9-4de1-a636-72d48343f803)
Author
Owner

@jlengelbrecht commented on GitHub (Aug 26, 2024):

@jlengelbrecht I have just released version 3.3.0. This option now has support for the confidential flow that I think UID needs. Ensure the following environment variables are set:

AUTH_OIDC_CLIENT_TYPE=confidential
AUTH_OIDC_CLIENT_SECRET=

AUTH_OIDC_CLIENT_SECRET should contain the secret given by UID

The full guide can be found here: https://github.com/glenndehaan/unifi-voucher-site#configuration-2

Thank you for updating this. You have put a lot of work into this. I really appreciate it. I will test this shortly still working on getting traefik back up and running.

<!-- gh-comment-id:2311148749 --> @jlengelbrecht commented on GitHub (Aug 26, 2024): > @jlengelbrecht I have just released version 3.3.0. This option now has support for the confidential flow that I think UID needs. Ensure the following environment variables are set: > > ``` > AUTH_OIDC_CLIENT_TYPE=confidential > AUTH_OIDC_CLIENT_SECRET= > ``` > > `AUTH_OIDC_CLIENT_SECRET` should contain the secret given by UID > > The full guide can be found here: https://github.com/glenndehaan/unifi-voucher-site#configuration-2 Thank you for updating this. You have put a lot of work into this. I really appreciate it. I will test this shortly still working on getting traefik back up and running.
Author
Owner

@jlengelbrecht commented on GitHub (Aug 27, 2024):

@glenndehaan Got my proxy issue sorted. Did some more testing with the new changes you made. Setting the OIDC_CLIENT_TYPE as confidential. Still getting a errorCode=E_U_APP_OIDC_NOT_MATCH_REDIRECT_URL error. Here is what I set my values to. UID requires the Initiate Sign-In URI so I set it to /login. Using /callback for the Sign-In Redirect URL doesn't seem to work the confidential flow type. I also tested using a wildcard /* like you recommended earlier. Same result.

<!-- gh-comment-id:2311520023 --> @jlengelbrecht commented on GitHub (Aug 27, 2024): @glenndehaan Got my proxy issue sorted. Did some more testing with the new changes you made. Setting the `OIDC_CLIENT_TYPE` as confidential. Still getting a `errorCode=E_U_APP_OIDC_NOT_MATCH_REDIRECT_URL` error. Here is what I set my values to. UID requires the `Initiate Sign-In URI` so I set it to `/login`. Using `/callback` for the Sign-In Redirect URL doesn't seem to work the confidential flow type. I also tested using a wildcard `/*` like you recommended earlier. Same result.
Author
Owner

@jlengelbrecht commented on GitHub (Aug 27, 2024):

@glenndehaan nevermind got it to work using the confidential flow. My proxy issue from earlier required me to change my domain. Going over the config I forgot to take out the the old domain from the docker-compose file. I ended up setting the Sign-In Redirect URL to /callback and the Initiate Sign-In URI to my-domain.com.

OIDC now works from within UID, but when accessing the app via the url from outside of UID, you are still redirected to https://my-domain.com/login which then asks for a password. Is this expected? The documentation mentions that when OIDC is used the password would be disabled, but this does not seem to be the case.

<!-- gh-comment-id:2311543198 --> @jlengelbrecht commented on GitHub (Aug 27, 2024): @glenndehaan nevermind got it to work using the `confidential` flow. My proxy issue from earlier required me to change my domain. Going over the config I forgot to take out the the old domain from the docker-compose file. I ended up setting the Sign-In Redirect URL to `/callback` and the Initiate Sign-In URI to `my-domain.com`. OIDC now works from within UID, but when accessing the app via the url from outside of UID, you are still redirected to `https://my-domain.com/login` which then asks for a password. Is this expected? The documentation mentions that when OIDC is used the password would be disabled, but this does not seem to be the case.
Author
Owner

@glenndehaan commented on GitHub (Aug 27, 2024):

@jlengelbrecht That is great to hear. In terms of the original login page. This should indeed be disabled since UID should now handle the authentication even if you direct access the app. Are you dropped onto the app's password only page?

<!-- gh-comment-id:2311681546 --> @glenndehaan commented on GitHub (Aug 27, 2024): @jlengelbrecht That is great to hear. In terms of the original login page. This should indeed be disabled since UID should now handle the authentication even if you direct access the app. Are you dropped onto the app's password only page?
Author
Owner

@glenndehaan commented on GitHub (Aug 27, 2024):

Ah also before I forget if you have some time, and are willing to create a small readme on how to configure UID. I want to create a list of 'tested' idP's with some short guides on how to set them up. It would be great if you could provide some details and some screenshots (also since docs about UID are already in short supply) (of course without private info). Could be an MR or just post it here, then I will convert it and will provide credits within the file to you

<!-- gh-comment-id:2311700576 --> @glenndehaan commented on GitHub (Aug 27, 2024): Ah also before I forget if you have some time, and are willing to create a small readme on how to configure UID. I want to create a list of 'tested' idP's with some short guides on how to set them up. It would be great if you could provide some details and some screenshots (also since docs about UID are already in short supply) (of course without private info). Could be an MR or just post it here, then I will convert it and will provide credits within the file to you
Author
Owner

@jlengelbrecht commented on GitHub (Aug 27, 2024):

@jlengelbrecht That is great to hear. In terms of the original login page. This should indeed be disabled since UID should now handle the authentication even if you direct access the app. Are you dropped onto the app's password only page?

@glenndehaan Yeah, if I access the application externally, I am redirected to the login page that you would normally see when you hit access the app without OIDC and am prompted for a password. However, when accessing from within UID, I am signed in automatically.

<!-- gh-comment-id:2312324786 --> @jlengelbrecht commented on GitHub (Aug 27, 2024): > @jlengelbrecht That is great to hear. In terms of the original login page. This should indeed be disabled since UID should now handle the authentication even if you direct access the app. Are you dropped onto the app's password only page? @glenndehaan Yeah, if I access the application externally, I am redirected to the login page that you would normally see when you hit access the app without OIDC and am prompted for a password. However, when accessing from within UID, I am signed in automatically.
Author
Owner

@jlengelbrecht commented on GitHub (Aug 27, 2024):

Ah also before I forget if you have some time, and are willing to create a small readme on how to configure UID. I want to create a list of 'tested' idP's with some short guides on how to set them up. It would be great if you could provide some details and some screenshots (also since docs about UID are already in short supply) (of course without private info). Could be an MR or just post it here, then I will convert it and will provide credits within the file to you

@glenndehaan Absolutely. I will create a PR later today or tomorrow for UID. Then, link it back to the main README.md in a table of tested IDPs.

<!-- gh-comment-id:2312330420 --> @jlengelbrecht commented on GitHub (Aug 27, 2024): > Ah also before I forget if you have some time, and are willing to create a small readme on how to configure UID. I want to create a list of 'tested' idP's with some short guides on how to set them up. It would be great if you could provide some details and some screenshots (also since docs about UID are already in short supply) (of course without private info). Could be an MR or just post it here, then I will convert it and will provide credits within the file to you @glenndehaan Absolutely. I will create a PR later today or tomorrow for UID. Then, link it back to the main README.md in a table of tested IDPs.
Author
Owner

@glenndehaan commented on GitHub (Aug 27, 2024):

@glenndehaan Yeah, if I access the application externally, I am redirected to the login page that you would normally see when you hit access the app without OIDC and am prompted for a password. However, when accessing from within UID, I am signed in automatically.

That is weird since that view should not even be loaded within the app when the OIDC variables are set. I did read back the whole conversation we had, and at some point you mentioned you had 2 instances running, one with OIDC and one without. Are you sure you are using the one with OIDC enabled? If so could you have a look at the logs on start of the container to see if you get a '[JWT]' message?

<!-- gh-comment-id:2312397741 --> @glenndehaan commented on GitHub (Aug 27, 2024): > @glenndehaan Yeah, if I access the application externally, I am redirected to the login page that you would normally see when you hit access the app without OIDC and am prompted for a password. However, when accessing from within UID, I am signed in automatically. That is weird since that view should not even be loaded within the app when the OIDC variables are set. I did read back the whole conversation we had, and at some point you mentioned you had 2 instances running, one with OIDC and one without. Are you sure you are using the one with OIDC enabled? If so could you have a look at the logs on start of the container to see if you get a '[JWT]' message?
Author
Owner

@glenndehaan commented on GitHub (Aug 27, 2024):

@glenndehaan Absolutely. I will create a PR later today or tomorrow for UID. Then, link it back to the main README.md in a table of tested IDPs.

Thanks man awesome. I will push an update later this evening to add the initial Keycloak and Authentik docs.

<!-- gh-comment-id:2312399546 --> @glenndehaan commented on GitHub (Aug 27, 2024): > @glenndehaan Absolutely. I will create a PR later today or tomorrow for UID. Then, link it back to the main README.md in a table of tested IDPs. Thanks man awesome. I will push an update later this evening to add the initial Keycloak and Authentik docs.
Author
Owner

@aroundmyroom commented on GitHub (Aug 30, 2024):

@jlengelbrecht @glenndehaan trying to check the manual and test the OIDC with keycloak. I have an up and running SSO with proxmox, so I know that things can work

What do I wrong as I get no login or redirect, I cannot access http://voucher.xxx.net:3000/callback (page not found)
in the log of @jlengelbrecht I see that OIDC is mentioned, but I do not see that.

I do not have docker, so I pass the environment variables through my bin/bash script
all other env. do work: like mail, login etc..

I think this is the part what is necessary

export AUTH_PASSWORD='1234'
export AUTH_DISABLE='false'
export AUTH_OIDC_APP_BASE_URL: 'http://voucher.xxxx.net:3000'
export AUTH_OIDC_CLIENT_TYPE='public'
export AUTH_OIDC_CLIENT_ID: ''
export AUTH_OIDC_ISSUER_BASE_URL='https://sso.xxxx.net/realms/Production/.well-known/openid-configuration'
export AUTH_OIDC_CLIENT_SECRET: ''

When starting my shell, the login page is gone and I am in the app without being authorised (hence I even do not see a logout button)
What part am i missing?

I think I am missing something as I think I need to see that OIDC is enabled like what I saw here above:

2024-08-25 03:46:37.861 INFO [UniFi] Using Controller on: 10.20.66.1:443 (Site ID: default)
2024-08-25 03:46:37.867 INFO [OIDC] Set secret: 8xx352e
2024-08-25 03:46:37.961 INFO [OIDC] Issuer: https://my-domain.ui.com/gw/idp/api/v1/public/oauth/super-secret-token/.well-known/openid-configuration, Client: my-client-id

this I do not see when I start the tool

<!-- gh-comment-id:2320444887 --> @aroundmyroom commented on GitHub (Aug 30, 2024): @jlengelbrecht @glenndehaan trying to check the manual and test the OIDC with keycloak. I have an up and running SSO with proxmox, so I know that things can work What do I wrong as I get no login or redirect, I cannot access http://voucher.xxx.net:3000/callback (page not found) in the log of @jlengelbrecht I see that OIDC is mentioned, but I do not see that. I do not have docker, so I pass the environment variables through my bin/bash script all other env. do work: like mail, login etc.. I think this is the part what is necessary export AUTH_PASSWORD='1234' export AUTH_DISABLE='false' export AUTH_OIDC_APP_BASE_URL: 'http://voucher.xxxx.net:3000' export AUTH_OIDC_CLIENT_TYPE='public' export AUTH_OIDC_CLIENT_ID: '' export AUTH_OIDC_ISSUER_BASE_URL='https://sso.xxxx.net/realms/Production/.well-known/openid-configuration' export AUTH_OIDC_CLIENT_SECRET: '' When starting my shell, the login page is gone and I am in the app without being authorised (hence I even do not see a logout button) What part am i missing? I think I am missing something as I think I need to see that OIDC is enabled like what I saw here above: 2024-08-25 03:46:37.861 INFO [UniFi] Using Controller on: 10.20.66.1:443 (Site ID: default) 2024-08-25 03:46:37.867 INFO [OIDC] Set secret: 8xx352e 2024-08-25 03:46:37.961 INFO [OIDC] Issuer: https://my-domain.ui.com/gw/idp/api/v1/public/oauth/super-secret-token/.well-known/openid-configuration, Client: my-client-id this I do not see when I start the tool
Author
Owner

@glenndehaan commented on GitHub (Aug 30, 2024):

I see a lot of red flags here.

First I need logs. Without logs I don't know what the app is doing. So please strip confidential info and upload the logs of the startup sequence.

Second local hosting without docker as already said within other posts is not recommended since after large refactors code can be messed up of not properly updated. (And the auth refactor was a big one, hence the v3 generation)

Third i'm seeing a mismatch in the app and IdP transport. Your app is now running on http and the IdP on https. This can cause trouble.

Fourth the AUTH_OIDC_CLIENT_ID can't be empty. This needs to contain the client id created in keycloak.

Fifth you are mixing variables. If you are going to OIDC then drop the AUTH_PASSWORD and AUTH_DISABLE These are not required.

Sixth the callback url you mentioned is a POST request. This leads me to believe you have not used OAuth before? If that is the case then debugging this will become an issue since this is not an easy topic.

<!-- gh-comment-id:2320495601 --> @glenndehaan commented on GitHub (Aug 30, 2024): I see a lot of red flags here. First I need logs. Without logs I don't know what the app is doing. So please strip confidential info and upload the logs of the startup sequence. Second local hosting without docker as already said within other posts is not recommended since after large refactors code can be messed up of not properly updated. (And the auth refactor was a big one, hence the v3 generation) Third i'm seeing a mismatch in the app and IdP transport. Your app is now running on http and the IdP on https. This can cause trouble. Fourth the `AUTH_OIDC_CLIENT_ID` can't be empty. This needs to contain the client id created in keycloak. Fifth you are mixing variables. If you are going to OIDC then drop the `AUTH_PASSWORD` and `AUTH_DISABLE` These are not required. Sixth the callback url you mentioned is a POST request. This leads me to believe you have not used OAuth before? If that is the case then debugging this will become an issue since this is not an easy topic.
Author
Owner

@aroundmyroom commented on GitHub (Aug 30, 2024):

Ok added some items to my script to get proper debugging..

have it working now ..
your input gave me some extra info needed. (remiving the auth_password and auth_disable), Which I probably overlooked reading in the howto.
Thanks ..

<!-- gh-comment-id:2320556397 --> @aroundmyroom commented on GitHub (Aug 30, 2024): Ok added some items to my script to get proper debugging.. have it working now .. your input gave me some extra info needed. (remiving the auth_password and auth_disable), Which I probably overlooked reading in the howto. Thanks ..
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/unifi-voucher-site#18
No description provided.