Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SF-3117 Add option to remove branding from auth0 page #2937

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

RaymondLuong3
Copy link
Collaborator

@RaymondLuong3 RaymondLuong3 commented Jan 8, 2025

This PR calls the Auth0 login API with the additional useBranding and logo parameters that will configure Auth0 to hide the SF name and SIL logo when using a site other than localhost or scriptureforge.org.
I marked this as testing not required since it won't be testable until the non-branded site is live. A developer can test this by setting useBranding to false.

Auth0 Login White Label
Auth0 Change Password White Label


This change is Reviewable

@@ -243,11 +245,15 @@
const state: AuthState = { returnUrl };
const language: string = getAspCultureCookieLanguage(this.cookieService.get(ASP_CULTURE_COOKIE_NAME));
const ui_locales: string = language;
const useBranding: boolean =
this.locationService.origin.includes('scriptureforge.org') || this.locationService.origin.includes('localhost');

Check failure

Code scanning / CodeQL

Incomplete URL substring sanitization High

'scriptureforge.org' can be anywhere in the URL, and arbitrary hosts may come before or after it.

Copilot Autofix AI 9 days ago

To fix the problem, we need to parse the URL and check its host value against a whitelist of allowed hosts. This ensures that the check is not bypassed by embedding the allowed host in an unexpected location within the URL.

  1. Parse the URL to extract the host.
  2. Check if the host is in a predefined list of allowed hosts.
  3. Replace the substring check with this more secure approach.

We will need to import the URL module to parse the URL and define a list of allowed hosts.

Suggested changeset 1
src/SIL.XForge.Scripture/ClientApp/src/xforge-common/auth.service.ts

Autofix patch

Autofix patch
Run the following command in your local git repository to apply this patch
cat << 'EOF' | git apply
diff --git a/src/SIL.XForge.Scripture/ClientApp/src/xforge-common/auth.service.ts b/src/SIL.XForge.Scripture/ClientApp/src/xforge-common/auth.service.ts
--- a/src/SIL.XForge.Scripture/ClientApp/src/xforge-common/auth.service.ts
+++ b/src/SIL.XForge.Scripture/ClientApp/src/xforge-common/auth.service.ts
@@ -1,2 +1,3 @@
 import { Injectable } from '@angular/core';
+import { URL } from 'url';
 import { Router } from '@angular/router';
@@ -247,4 +248,5 @@
     const ui_locales: string = language;
-    const useBranding: boolean =
-      this.locationService.origin.includes('scriptureforge.org') || this.locationService.origin.includes('localhost');
+    const allowedHosts = ['scriptureforge.org', 'localhost'];
+    const url = new URL(this.locationService.origin);
+    const useBranding: boolean = allowedHosts.includes(url.host);
     const auth0Parameters: xForgeAuth0Parameters = {
EOF
@@ -1,2 +1,3 @@
import { Injectable } from '@angular/core';
import { URL } from 'url';
import { Router } from '@angular/router';
@@ -247,4 +248,5 @@
const ui_locales: string = language;
const useBranding: boolean =
this.locationService.origin.includes('scriptureforge.org') || this.locationService.origin.includes('localhost');
const allowedHosts = ['scriptureforge.org', 'localhost'];
const url = new URL(this.locationService.origin);
const useBranding: boolean = allowedHosts.includes(url.host);
const auth0Parameters: xForgeAuth0Parameters = {
Copilot is powered by AI and may make mistakes. Always verify output.
Unable to commit as this autofix suggestion is now outdated
Positive Feedback
Negative Feedback

Provide additional feedback

Please help us improve GitHub Copilot by sharing more details about this comment.

Please select one or more of the options
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This alert is correct. We should be making an exact check for location.host or location.hostname (the difference being that host includes the port, so it would be localhost:5000 locally).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I have it working as per the suggestion here.

Copy link

codecov bot commented Jan 8, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.96%. Comparing base (c433724) to head (cea0ea1).

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #2937   +/-   ##
=======================================
  Coverage   81.96%   81.96%           
=======================================
  Files         545      545           
  Lines       31536    31536           
  Branches     5090     5112   +22     
=======================================
  Hits        25850    25850           
+ Misses       4939     4927   -12     
- Partials      747      759   +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@marksvc marksvc self-assigned this Jan 9, 2025
Copy link
Collaborator

@marksvc marksvc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested locally and it is working for me.

I observe that the SF name is being used rather than "Log In", when at a useBranding===true site. If a change for that was supposed to be included here.

Reviewed 2 of 2 files at r3, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @Github-advanced-security[bot] and @RaymondLuong3)


src/SIL.XForge.Scripture/ClientApp/src/xforge-common/auth.service.spec.ts line 436 at r3 (raw file):

  }));

  it('should login with branding', fakeAsync(() => {

I think you mean 'without' ?


src/SIL.XForge.Scripture/ClientApp/src/xforge-common/auth.service.ts line 257 at r3 (raw file):

      login_hint: ui_locales,
      useBranding,
      logo: 'https://auth0.languagetechnology.org/assets/sf.svg'

From just this code file, it seems a little odd that this logo isn't used, when useBranding===false.

@marksvc
Copy link
Collaborator

marksvc commented Jan 9, 2025

src/SIL.XForge.Scripture/ClientApp/src/xforge-common/auth.service.ts line 257 at r3 (raw file):

Previously, marksvc wrote…

From just this code file, it seems a little odd that this logo isn't used, when useBranding===false.

A possible improvement would be for the login page to always use the logo, if specified.
An alternate possible improvement would be to put a comment in interface xForgeAuth0Parameters on logo, saying something like "Log in/Sign up page logo to use when useBranding===false".
It's also not the end of the world.

@Nateowami
Copy link
Collaborator

@RaymondLuong3 This part of the Jira issue doesn't appear to have been addressed:

Also, there's an idiosyncrasy in that the login page says "Scripture Forge" at the top, but signup page says "Sign Up" at the top. This would be a good time to address that.

I also don't really see a value in having two different appearances.

@marksvc
Copy link
Collaborator

marksvc commented Jan 9, 2025

two different appearances

As in one display with the SIL logo, and one display with the SF logo?

Copy link
Collaborator

@marksvc marksvc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I approve. Tho you may still want to address some of these above comments in the same PR.

Reviewed 1 of 1 files at r4, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @Github-advanced-security[bot] and @RaymondLuong3)

Copy link
Collaborator Author

@RaymondLuong3 RaymondLuong3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the suggestions. I have made the update to the auth0 config repo to use the logo when it is provided. I've also updated the code there so that the Login and Signup tabs and titles match the widget title.

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @Github-advanced-security[bot])


src/SIL.XForge.Scripture/ClientApp/src/xforge-common/auth.service.ts line 257 at r3 (raw file):

Previously, marksvc wrote…

A possible improvement would be for the login page to always use the logo, if specified.
An alternate possible improvement would be to put a comment in interface xForgeAuth0Parameters on logo, saying something like "Log in/Sign up page logo to use when useBranding===false".
It's also not the end of the world.

Thanks. That makes sense. When you try it now the logo provided will always be used.


src/SIL.XForge.Scripture/ClientApp/src/xforge-common/auth.service.spec.ts line 436 at r3 (raw file):

Previously, marksvc wrote…

I think you mean 'without' ?

Good catch!

Copy link
Collaborator

@marksvc marksvc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @Github-advanced-security[bot])


src/SIL.XForge.Scripture/ClientApp/src/xforge-common/auth.service.ts line 257 at r3 (raw file):

Previously, RaymondLuong3 (Raymond Luong) wrote…

Thanks. That makes sense. When you try it now the logo provided will always be used.

I confirm that the SF logo is used in both the useBranding or not-useBranding cases.
Since in both cases the same logo and words are shown, I wonder if SF-3117 should be a SF fix after all? Oh I guess for other applications using the auth0 tennant, they might still want the SIL logo.
But perhaps now the useBranding might not be meaningful?

Copy link
Collaborator Author

@RaymondLuong3 RaymondLuong3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @Github-advanced-security[bot] and @marksvc)


src/SIL.XForge.Scripture/ClientApp/src/xforge-common/auth.service.ts line 257 at r3 (raw file):

Previously, marksvc wrote…

I confirm that the SF logo is used in both the useBranding or not-useBranding cases.
Since in both cases the same logo and words are shown, I wonder if SF-3117 should be a SF fix after all? Oh I guess for other applications using the auth0 tennant, they might still want the SIL logo.
But perhaps now the useBranding might not be meaningful?

Aha, yes I see. By just providing the logo we do not need to specify the useBranding parameter. I've removed it.

@RaymondLuong3 RaymondLuong3 requested a review from marksvc January 13, 2025 22:57
Copy link
Collaborator

@marksvc marksvc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 2 of 2 files at r5, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @Github-advanced-security[bot])

@Nateowami
Copy link
Collaborator

@RaymondLuong3 Is this PR title still accurate?

@RaymondLuong3
Copy link
Collaborator Author

Yes, essentially still accurate on the user facing level.

@Nateowami
Copy link
Collaborator

I couldn't really understand how this is "adding an option;" it seems more so to be just "remove branding." Maybe an option was added on the Auth0 side? I see an option on the Auth0 side that's an unmerged PR, meaning this PR isn't really ready to merge, if I'm understanding things correctly. I almost merged this this morning but the code changes and the title didn't seem to match, which is the only reason I held off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants