Hi Mark,
Sorry for the long delay in responding. I figured out the problem was I was using user.data.firstName, etc... for the built-in profile fields. Instead, it should be user.firstName. It's working fine now; thank you for the guidance on how to debug it!
@dan No, nothing that seemed relevant. I ended up using Cloudflare as a proxy. That works fine, but it would be simpler to just enable HTTPS in FusionAuth.
@dan It doesn't seem fair that you can't modify a form without a license. I don't need to do anything elaborate, just rearrange some of the fields in the Admin User Form, delete fields I'm not using, and add the firstName field to the form. firstName should be one of the standard fields anyway.
I'm running v1.47.1. It's installed on a Ubuntu 22 server from your Debian package. I'm using Chrome, but the field is not present at all in the HTML, so the browser wouldn't matter. I haven't installed it locally, but I'm not sure what that would prove. The field shows up for you, so clearly it's supposed to be there. Perhaps the issue is specific to the Debian package. Everything else works fine, so I assume it was some oversight during the build process.
Our customers frequently complain about this error message when they're trying to log in. I did a remote support session on the computer of a customer who couldn't login and discovered he'd bookmarked the FusionAuth IdP URL, rather than the URL of the correct SAML starting point on the SP.
I understand why it's happening, but I feel that FusionAuth should handle this more gracefully. Currently, it displays this ugly, technical error message and advises them to use the back button, which will accomplish nothing, since their starting point in the SAML flow is incorrect.
Ideally, it should just redirect them to the correct URL on the SP, so the SAML flow can proceed normally. You can't expect customers to know the difference between an IdP and an SP and to know that it's incorrect to bookmark the login page. I think most people would assume the login page is where they should go to login, so it's reasonable for them to bookmark that page.
If it's not possible to redirect them automatically, I'd like to ask if it's possible to customize this error page. If that's possible, I'd get rid of all this confusing text and the ugly error message and just provide a link to the SP URL. 
I upgraded. I haven't tried a new install nor do I want to. I understand why it's happening. Is it something you can fix in a future update, without my having to start over with a whole new install?
@dan I'm now on 1.53.2, but the First Name field still doesn't appear on the User Profile form. I noticed in the Github issue, they wrote:
We are naming the user.firstName field [Admin Registration : first name instead of [Admin User] first name so when we go build the default form we don't find a result because we look up the field with WHERE name = '[Admin User] first name'.
Therefore, I changed the field name in Customizations->Form Fields to [Admin User] first name.
Next, I edited the form and added the field. However, when I try to save the form, it says:
To modify a form that is currently in use must activate the Reactor with a valid license key.
When I navigate to the Reactor page, it shows that it's licensed with a Community Edition license.
Hi Mark,
Sorry for the long delay in responding. I figured out the problem was I was using user.data.firstName, etc... for the built-in profile fields. Instead, it should be user.firstName. It's working fine now; thank you for the guidance on how to debug it!
I sometimes see 404 errors in the SP server log like the following:
2607:fb90:3f86:d16e:28de:bbcb:c285:4edf - - [04/Apr/2024:09:25:43 -0400] "POST /login/Saml HTTP/2" 302 - "https://auth.clinicalmatchme.com/" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Mobile Safari/537.36"
2607:fb90:3f86:d16e:28de:bbcb:c285:4edf - - [04/Apr/2024:09:25:44 -0400] "GET /js/prime-min-1.6.4.js?version=1.48.1 HTTP/2" 404 139 "-" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Mobile Safari/537.36"
2607:fb90:3f86:d16e:28de:bbcb:c285:4edf - - [04/Apr/2024:09:25:44 -0400] "GET /css/fusionauth-style.css?version=1.48.1 HTTP/2" 404 139 "-" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Mobile Safari/537.36"
2607:fb90:3f86:d16e:28de:bbcb:c285:4edf - - [04/Apr/2024:09:25:44 -0400] "GET /js/oauth2/LocaleSelect.js?version=1.48.1 HTTP/2" 404 139 "-" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Mobile Safari/537.36"
2607:fb90:3f86:d16e:28de:bbcb:c285:4edf - - [04/Apr/2024:09:25:44 -0400] "GET /js/jstz-min-1.0.6.js HTTP/2" 404 139 "-" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Mobile Safari/537.36"
2607:fb90:3f86:d16e:28de:bbcb:c285:4edf - - [04/Apr/2024:09:25:43 -0400] "GET / HTTP/2" 302 - "https://auth.clinicalmatchme.com/" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Mobile Safari/537.36"
2607:fb90:3f86:d16e:28de:bbcb:c285:4edf - - [04/Apr/2024:09:25:44 -0400] "GET /css/font-awesome-4.7.0.min.css HTTP/2" 404 139 "-" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Mobile Safari/537.36"
2607:fb90:3f86:d16e:28de:bbcb:c285:4edf - - [04/Apr/2024:09:25:44 -0400] "GET /js/Util.js?version=1.48.1 HTTP/2" 404 139 "-" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Mobile Safari/537.36"
2607:fb90:3f86:d16e:28de:bbcb:c285:4edf - - [04/Apr/2024:09:25:44 -0400] "GET /js/oauth2/Authorize.js?version=1.48.1 HTTP/2" 404 139 "-" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Mobile Safari/537.36"
2607:fb90:3f86:d16e:28de:bbcb:c285:4edf - - [04/Apr/2024:09:25:44 -0400] "GET /js/identityProvider/InProgress.js?version=1.48.1 HTTP/2" 404 139 "-" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Mobile Safari/537.36"
Although these errors are occurring on the SP server, they're being triggered by the FusionAuth theme on the IdP server. In the first request, the user is being redirected to FusionAuth to start the login process. When it loads the FusionAuth theme template, it requests all those files, but instead of requesting them from the IdP server, it's requesting them from the SP server, but they don't exist there, hence the 404 errors.
In the theme template, I see lines like this:
<script src="${request.contextPath}/js/prime-min-1.6.4.js?version=${version}"></script>
So it seems the ${request.contextPath} variable is being incorrectly populated with the SP hostname, rather then the IdP hostname. I'm running FusionAuth 1.48.1 on a Ubuntu 22 server. I want to emphasize that this only happens every once in a while. Most of the time, users login without triggering these errors and I don't know under what conditions this happens.
Screenshot below. I can't provide sample code because the integration is with a third-party application. However, when I enable debug mode in that application, it logs the JWT token it's receiving from FusionAuth:
{"aud":"bfa366a7-9e50-4df3-82d5-d111028370f1","exp":1706394906,"iat":1706391306,"iss":"clinicalmatchme.com","sub":"c975ef0e-eb44-412c-b8ad-766177677da2","jti":"2497e0e4-97e2-46ee-a5b8-4d691a79
f13b","authenticationType":"PASSWORD","email":"brad@hostland.com","email_verified":true,"at_hash":"5f5J3oDmyYCplIBG8J8Vig","c_hash":"GuLPkMegupiDHNt_xOcVQg","scope":"openid profile email","nonce":"plwzij","sid":"93dd553e-0742-4675-906e-0f59
fc0ef3df","auth_time":1706391306,"tid":"035c049b-5e2e-11ee-877a-02904e6a3dbf"}
You can see the profile scope is present, but FA is not sending any of the profile info, even with the lambda function enabled.
I'm using FusionAuth as the OIDC IdP for an application. The application is configured to include the profile scope in the authentication request, but when FusionAuth sends the JWT token, it doesn't include any of the profile fields. Shouldn't it send the profile fields automatically when the profile scope is included in the request?
Anyway, I tried to force it to send the profile data using the following lambda function:
function populate(jwt, user, registration) {
jwt.name = user.data.fullName;
jwt.family_name = user.data.lastName;
jwt.given_name = user.data.firstName;
}
After creating this lambda, I enabled it in the JWT tab for the application. It's selected for both Access Token populate lambda and Id Token populate lambda, but it doesn't seem to do anything. It's still sending the JWT token without these fields.
@dan The database backend is AWS Aurora, and it's a big production instance, so it's unlikely that it would run out of connections. Also, other apps running on the same database continued to work fine. FusionAuth is currently in testing. Since we only have a couple of users testing it, the load is extremely light, so I don't see how it could have been under extereme load.