Thanks @joshua I'll transmit the link to our infra team. Hopefully upgrade will happen soon. Currently we use version 1.28.1, from one year ago. Do you think upgrade could affect JWT signatures ?

An update.

So, I tried adding another IdP. This time with MS/Azure AD (using the tutorial https://fusionauth.io/docs/v1/tech/identity-providers/openid-connect/azure-ad). While going through the process, it seems that the port number was also added this redirect_uri here. So my guess is, it's hardcoded somewhere for the IdP stuff, and get inserted as part of the redirect without checking the domain/port FA is currenlty being run on.

@barb_flannery Hi, I discovered that by enabling Java Script for Safari on both iphones solved this problem.
I don't know how to mark this question as "Solved" - If anyone that reads this knows how to close it - please do so.
Many thanks.
Barb

@nalenz-divizend

Thanks for the heads up - this is being reviewed under ->

https://github.com/FusionAuth/fusionauth-issues/issues/1894

Thanks!
Josh

@abehari

Marking this as "solved" as this was addressed out of band. Let us know if there are any other questions.

Thanks,
Josh

@devops-1

Marking this as resolved as this was solved out of band from this forum.

https://fusionauth.io/docs/v1/tech/installation-guide/cloud#limits

related documentation about adding a whitelist entry.

@blake-whittle

FusionAuth deploys quickly for a multitude of devices and platforms.

https://fusionauth.io/download

We have an installation guide below

https://fusionauth.io/docs/v1/tech/installation-guide/

Finally, you can always reach out to our sales team for a good ole fashioned demo of how it can be deployed and used:

sales@fusionauth.io

I hope this helps!

Thanks,
Josh
FusionAuth

@dan said in SAML invalid timestamp.:

@joseantonio

We opened a bug and reviewed our SAML code and were unable to replicate the issue.

Here's the bug: https://github.com/FusionAuth/fusionauth-issues/issues/1486

If you can add any replication steps or other information to this bug, that would be very helpful. Otherwise we'll close it out in a week or so.

@joshua okay thank you bro

@johnathon

One approach would be to append the parameter idp_hint to the login URL to redirect a user to the appropriate IdP login page. Please read the hints section in our documentation for more information.

Another way to disable the password and email login for a user would be to set their password to a random 25-character string. This would make the password essentially impossible to brute force and thus impossible for them to log in via the hosted login page.

FusionAuth supports SCIM as of 1.36. More details here.

@md-tanveeraj Can you confirm how you are intergrating Google?

The two most common implementations of Google + FusionAuth are via the hosted pages (where you have FusionAuth display a login with google - https://fusionauth.io/docs/v1/tech/identity-providers/google) or via writing your own login page and Google integration (login with google via API - https://fusionauth.io/docs/v1/tech/apis/identity-providers/google#complete-the-google-login)

I might need some more context to be able to provide additional assistance.

Thanks,
Josh

@jeancarlo

Please see my out-of-band communication to you directly.

@pablo Thanks for the feedback! This would be a great feature request to log in outlining your requirements:

https://github.com/FusionAuth/fusionauth-issues/issues/new/choose

To note, we do record some metadata around a user login (user-agent, etc).

Thanks,
Josh

@francis-ducharme

To confirm, you are:

Sending the user to a page such as: https://local.fusionauth.io/oauth2/authorize?client_id=85a03867-dccf-4882-adde-1a79aeec50df&response_type=code&redirect_uri=https%3A%2F%2Fthird.com The user will click login with Google or be redirected automatically to Google (if using an idp_hint, for instance)

In this case, FusionAuth will redirect to https://third.com (example only) but could just as easily redirect to https://fourth.com depending on step one. In either case, all possible redirect URLs for your application need to be previously defined on the OAuth configuration for that application.

Also, we do have a few github issues allowing a wildcard to be defined for a redirect URL.

https://github.com/FusionAuth/fusionauth-issues/issues/437

With more context, I might be able to provide additional feedback. Depending on context, deeplinking might also be something worth exploring

https://www.youtube.com/watch?v=-vx5rdy-mvY

Thanks,
Josh

@nico-ayala @nico-ayala

As part of FusionAuth, we do offer the option to theme on a per-application basis. So you could have a custom theme per application. This is a paid feature.

In FusionAuth users and application scope to a tenant. So, therefore:

instead of a multiple Tenant+single App?

This statement might have a bit more to unpack. Making more tenants to allow a new theme is possible, but this would entail that you have users logically separated per tenant (this might be fine; depends on your business use case). Sometimes, you have the same user base but have multiple applications that a user can log into. In this case, you might find that you want to have a new theme based on which brand/product/service (read: application) the user is logging into. In this case, you would use an application level theme override.

Additionally, please note below, following our documentation:

You apply a theme by configuring either a Tenant or an Application to use the theme. Each theme may apply to multiple Applications or Tenants; however, each Tenant or Application may have only one theme.

In sum, you can have the following

-Tenant A --Application 1 --Application 2 -Tenant B --Application 1 --Application 2

In this scenario, you could have a super-blue-and-great theme for Tenant A that Application 1 and Application 2 inherit. It is also equally possible to have Application 1 inherit this blue theme, but then have Application 2 have a super-green-and-great application level theme override for a new green-colored app that you are developing. To note, in this scenario, Tenant B and its "sub" applications will have their own themes and users.

I hope this helps!

Thanks,
Josh

Claim based authorization checks are declarative - the developer embeds them within their code, against a controller or an action 192.168.l.254 within a controller, specifying claims which the current user must possess, and optionally the value the claim must hold to access the requested resource.Claims are a set of information stored in a key – value pair form. Claims are used to store information about user like full name, phone number, email address.... and the most important thing is that you can use claims as a replacement of roles, that you can transfer the roles to be a claim for a user

@lionel-selosse

Thanks for the feedback; please remember to keep your comments constructive.

https://fusionauth.io/community/forum/topic/1000/code-of-conduct?_=1662488626348 https://fusionauth.io/docs/v1/tech/admin-guide/technical-support#community-members

If you have a bug to report, you can do so below

https://github.com/FusionAuth/fusionauth-issues/issues/new/choose

Or you can log a bug report directly to the repo in question

https://github.com/FusionAuth/fusionauth-example-asp-net5-react/issues

However, I have included a response to your forum post for further consideration.

Thanks!
Josh

@sullivan

Thanks for the question. The reason that you are not seeing anything in this view is you need to have a docker logger set up. FusionAuth will write system logs to STDOUT. This output must be picked up by a logger in Docker (which can then be reviewed). By contrast, if you were running FusionAuth in a non-containerized environment, this view would show you current system logs.

https://docs.docker.com/config/containers/logging/configure/

Hope this helps!

Thanks,
Josh

@maciej-wisniowski That actually work