-
-
Notifications
You must be signed in to change notification settings - Fork 5
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
base: master
Are you sure you want to change the base?
Conversation
@@ -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
Show autofix suggestion
Hide autofix suggestion
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.
- Parse the URL to extract the host.
- Check if the host is in a predefined list of allowed hosts.
- 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.
-
Copy modified line R2 -
Copy modified lines R249-R251
@@ -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 = { |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
Codecov ReportAll modified and coverable lines are covered by tests ✅
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. |
There was a problem hiding this 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.
Previously, marksvc wrote…
A possible improvement would be for the login page to always use the logo, if specified. |
@RaymondLuong3 This part of the Jira issue doesn't appear to have been addressed:
I also don't really see a value in having two different appearances. |
As in one display with the SIL logo, and one display with the SF logo? |
519eb72
to
5be3217
Compare
There was a problem hiding this 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)
There was a problem hiding this 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!
There was a problem hiding this 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?
5be3217
to
9a9d98d
Compare
There was a problem hiding this 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 theuseBranding
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.
74a063f
to
cea0ea1
Compare
There was a problem hiding this 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])
@RaymondLuong3 Is this PR title still accurate? |
Yes, essentially still accurate on the user facing level. |
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. |
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.
This change is