@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

Yes, you can do this.

There are a couple of different approaches, they both require a bit of glue code.

You could create a user in FusionAuth with a name like anon-<uuid>@example.com and a known random password. Then create a JWT for that account using the login API. Add info to that account, then if/when the user registers, transfer that account info to the new user. You could even update the email address of the anon-<uuid>@example.com account and reset their password. This would be accomplished via the user API.

An alternative approach is to use the Vend JWT API to create a JWT for your anonymous user. This can look like anything, it's entirely freeform. When the user registers, you can take the info referenced by that JWT and transfer it to the new user.

If these don't meet your needs, feel free to open a GitHub issue with a specific use case.

Different people use various items. You can do direct partnerships, as I've seen our vendors do with Duo, or you can roll your own ADFS, as I spoke with a company yesterday that was doing. If you're comparing options, I'd also look at Okta.

Go talk to the people who make identity products and ask them to sell it to you. It appears that you have no idea what you're asking, so it's either that or hire a consultant to tell you.

@cedric-baiker

Can you confirm what is failing when you attempted this? In other words, do you receive any error information in the system or events log?

Thanks,
Josh

@cyril-feraudet

I believe that you may be looking for this documentation below

If you are building your own login page:

https://fusionauth.io/docs/v1/tech/apis/identity-providers/google#complete-the-google-login

If you are using the identity providers that ship with FusionAuth on our hosted pages

https://fusionauth.io/docs/v1/tech/identity-providers/google

Hope this helps!

Thanks,
Josh
FusionAuth

@8mapta1 Thanks for the question.

I might need some context to be better able to assist. But generally, when you are opening an iframe, you will need to direct the actions to this window and the parent window from which it opened.

Can you confirm how you are doing this?

A quick search revealed a few tips, which depending on context may, or may not apply to your situation.

https://www.ramanean.com/how-to-do-a-redirect-in-parent-window-using-an-iframe/ https://www.edureka.co/community/83545/how-to-redirect-parent-window-from-an-iframe-action

Thanks,
Josh

@leandro-menagonzalez

I will mark this resolved as we discussed this out of band.

https://fusionauth.io/docs/v1/tech/installation-guide/cloud#restoring-from-backup

Thanks,
Josh
FusionAuth

@johnathon

These are the steps FusionAuth takes to check whether a password contains special characters:

Convert the Java String to a char[] (a char is a 16-bit unicode value in Java) Check each character c to determine whether it is a special character using
!Character.isAlphabetic(c) && !Character.isDigit(c) If any character in the string returns true for the above check, we consider it to contain a special character

@mark-0

I have not done this, but from looking at the Fastify JWT library, it looks pretty straight forward:

https://github.com/fastify/fastify-jwt#options

Since there's no Fastify FusionAuth integration, you need to pass the public and private key if you want to verify and sign the JWTs, respectively. Since FusionAuth is creating the JWT, in theory you could just pass the public key of an RSA keypair, since you'll never need to sign the JWT (haven't tested that though).

To add the keys to FusionAuth, you'll want to use Keymaster: https://fusionauth.io/docs/v1/tech/core-concepts/key-master

Hope that helps.

@mrstudyfirst I was recently researching this and decided to test Outseta to cover the majority of these requirements and get up and running quickly and affordably at first, and then Rewardful later for affiliate functionality.