Kenneth
KKinde
•Created by Kenneth on 4/4/2025 in #💻┃support
CORS Errors when using wildcards for allowed callback URLs
Any updates regarding this?
20 replies
KKinde
•Created by Kenneth on 4/4/2025 in #💻┃support
CORS Errors when using wildcards for allowed callback URLs
Thank you very much, looking forward to hopefully being able to simplify organization provisioning 🙂
20 replies
KKinde
•Created by Kenneth on 4/4/2025 in #💻┃support
CORS Errors when using wildcards for allowed callback URLs
Thanks for the feedback, no additional context or specific use cases for now. Let me know if the team does require any additional information, happy to get to the bottom of this.
20 replies
KKinde
•Created by Kenneth on 4/4/2025 in #💻┃support
CORS Errors when using wildcards for allowed callback URLs
Regarding reproduction of this behavior, if any other application within the environment in Kinde does contain explicit callback urls for a specific subdomain, and this subdomain is used for authenticating against a application with only wildcards, everything works fine. The CORS errors would only occur when ALL applications ONLY contain wildcards.
20 replies
KKinde
•Created by Kenneth on 4/4/2025 in #💻┃support
CORS Errors when using wildcards for allowed callback URLs
Thanks for the information, for now our organization provisioning system is simply adding callback url's for login and logout so nothing is really going wrong here.
Just wondering if it could be simplified and trying to understand why exactly behaviour is different in the below cases.
- Explicit callback urls for and work perfectly fine and everything is as expected.
- Wildcards being set as and are causing CORS errors on the /oauth2/token endpoint.
- Organization handle based callbacks set as and are not causing CORS errors but are not respecting the logout callback correctly, leaving us at the generic Kinde hosted screen.
In each of these cases domain.com would be our custom domain that's set-up with Kinde.
20 replies
KKinde
•Created by Kenneth on 4/4/2025 in #💻┃support
CORS Errors when using wildcards for allowed callback URLs
This works for login callbacks, but doesnt seem to work for logout callbacks, here we would also need the dynamic callback system in this case.
20 replies
KKinde
•Created by Kenneth on 4/4/2025 in #💻┃support
CORS Errors when using wildcards for allowed callback URLs
Also can we somehow add the organization's handle to our access token claims?
20 replies
KKinde
•Created by Kenneth on 4/4/2025 in #💻┃support
CORS Errors when using wildcards for allowed callback URLs
And can the handle of an organization be set via the Kinde Management API?
20 replies
KKinde
•Created by Kenneth on 4/4/2025 in #💻┃support
CORS Errors when using wildcards for allowed callback URLs
I will give this a try, but is it expected behavior then when working purely with wildcards that CORS errors can occur?
20 replies
KKinde
•Created by Kenneth on 4/4/2025 in #💻┃support
CORS Errors when using wildcards for allowed callback URLs
That's exactly what's happening yes. We were thinking about trying out wildcards since this makes managing organizations a slight bit simpler, but it seems to give some issues regarding CORS.
20 replies
KKinde
•Created by Kenneth on 7/4/2024 in #💻┃support
Changing API settings takes an incredibly long time
@viv (kinde) Everything seems to be working smoothly now, changes in API/Application configuration in the Kinde admin portal are now reflected instantly again in the authentication layer.
Thank you and thank you @Oli - Kinde for troubleshooting this issue and resolving it this quickly, much appreciated!
29 replies
KKinde
•Created by Kenneth on 7/4/2024 in #💻┃support
Changing API settings takes an incredibly long time
Is there any other information I can provide for further troubleshooting?
29 replies
KKinde
•Created by Kenneth on 7/4/2024 in #💻┃support
Changing API settings takes an incredibly long time
So sadly this does not solve the issue because we are trying to request an access token with the aud claim being ["SignalRAPI"] in this case.
29 replies
KKinde
•Created by Kenneth on 7/4/2024 in #💻┃support
Changing API settings takes an incredibly long time
29 replies
KKinde
•Created by Kenneth on 7/4/2024 in #💻┃support
Changing API settings takes an incredibly long time
Alright the request seems to succeed, because no audience is requested at all with this approach.
When you check https://jwt.io with such generated token you will see there is no value present in the aud claim :/
@viv (kinde)
29 replies
KKinde
•Created by Kenneth on 7/4/2024 in #💻┃support
Changing API settings takes an incredibly long time
@viv (kinde) I've dmed you the details.
29 replies
KKinde
•Created by Kenneth on 7/4/2024 in #💻┃support
Changing API settings takes an incredibly long time
I will check internally if we can do this.
29 replies
KKinde
•Created by Kenneth on 7/4/2024 in #💻┃support
Changing API settings takes an incredibly long time
It's strange, since I have de-authorized an application for an API and I'm still able to request M2M access tokens, hours later.
29 replies
KKinde
•Created by Kenneth on 7/4/2024 in #💻┃support
Changing API settings takes an incredibly long time
@viv (kinde) the problem is that I'm unable to to request an access token for an API/audience after it has been granted access via the Kinde API or the admin portal. I'm unable to request an access token in the first place due to the audience not being "known" by the authentication layer somehow.
29 replies
KKinde
•Created by Kenneth on 7/4/2024 in #💻┃support
Changing API settings takes an incredibly long time
@Oli - Kinde I just checked again to see if the API/application authorization would have come through and now after approximately 36 hours the changes are finally reflected in the authentication layer, not sure what exactly is happening here that's causing such delays.
29 replies