-
Notifications
You must be signed in to change notification settings - Fork 40
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
Support detangling protected URLs to send them to the correct browser #85
Comments
I just saw pull request #77 and thought the solution might be very similar to the O365 safelinks and URL shorteners. Though I couldn't quite see how BrowserSelect was meant to decide whether to check a specific URL for redirects (I assume a whitelist for such tests is required, but don't see one). Following any/all URLs to test redirects doesn't sound safe. |
I have updated that PR, and re-submitted it as PR #86 If it's simply a matter of following the redirect, you could add the mimecast domain to the redirect list. If there a way to expand the URL without following the redirect, I'd consider implementing (like the outlook safelinks). |
Try Browser Tamer - it simply matches on a substring and it works. |
You're welcome to try my fork, it has an option to follow redirects. https://github.com/lucasnz/BrowserSelect I have built in logic to expand O365 URLs. I could potentially build logic to expand mimecast URLs but looking at the doco that doesn't appear to be straight forward: https://integrations.mimecast.com/documentation/endpoint-reference/targeted-threat-protection-url-protect/decode-url/ |
For large corporations, it's becoming common to "protect" URLs sent via email, for example Mimecast.
Example: https://protect-au.mimecast.com/s/-xlzCr81nyt8ojwQRT7tQnq?domain=github.com
This URL redirects to https://www.github.com/ if opened in a browser.
Problem: BrowserSelect would detect the domain as protect-au.mimecast.com rather than github.com, so could not be expected to choose the correct browser automatically.
I'm not sure if a generic solution is possible for such URL protection (you'd have to follow the URL, under certain conditions, to look for a redirection - not desirable for some links!). I doubt these URL protection products comply to some 'standard' way of working to make a generic solution possible. If there's a lot of different/unique URL protection 'solutions' then this could be onerous, but if there's just a few I imagine it may be feasible to support a handful with some regex and limited testing of those.
Arguably if we could hand-make a regex/pattern for testing "protect-.mimecast.com/?domain=X" then we could duplicate all our rules for mimecast protected links, but this would get quite cumbersome if there's more than just mimecast or a lot of rules.
The text was updated successfully, but these errors were encountered: