External sites can be opened in the staff client
Bug #921740 reported by
Thomas Berezansky
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
| 2.1 |
Won't Fix
|
Undecided
|
Unassigned | ||
| 2.2 |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
The branch below fixes this in two ways:
1 - It adds a new open_external function for use by things like the portal page. This will open links in the user's default browser regardless of where they point to.
2 - It adds a component that implements the content-policy routines to intercept loads of pages. If they go to a http/https domain that the user is not currently logged into then the load is stopped and the default browser is opened instead.
I am unsure if this should be considered a security fix and thus backported as far back as it will go.
| Changed in evergreen: | |
| status: | New → In Progress |
| Changed in evergreen: | |
| status: | In Progress → New |
Revision history for this message
| Michael Peters (mrpeters) wrote | #1 |
| tags: | added: signedoff |
| Changed in evergreen: | |
| status: | New → Confirmed |
| Changed in evergreen: | |
| milestone: | none → 2.3.0-beta1 |
Revision history for this message
| Lebbeous Fogle-Weekley (lebbeous) wrote | #2 |
| Changed in evergreen: | |
| status: | Confirmed → Fix Committed |
| Changed in evergreen: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
Tested as best I could, seems to work as advertised. Always good to close a potential security hole.
user/mrpeters-
http://