This repository was archived by the owner on Apr 12, 2024. It is now read-only.
Improve location service to allow domain specific usernames and ! in password in url passthrough #3249
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ng in password This is a small improvement to the regex SERVER_MATCH that will allow angular to process urls with domain specific usernames and passwords with hashbang like below: http://domain&c5username:[email protected]/#home Otherwise, a JS error occurs because regex doesn't match route and framework doesn't execute request.
…sswords in the URL This is a small improvement to the regex SERVER_MATCH that will allow angular to process urls with domain specific usernames and passwords with special characters like below: http://domain&c5username:password%[email protected]/#home (user: domain\username, pass: password!) Otherwise, a JS error occurs because regex doesn't match route and framework doesn't execute request.
|
|
|
Nice diagram! 😄 Thanks, but this will be obsolete when #3533 lands. |
IgorMinar
pushed a commit
to IgorMinar/angular.js
that referenced
this pull request
Oct 10, 2013
The location service, and other portions of the application, were relying on a complicated regular expression to get parts of a URL. But there is already a private urlUtils provider, which relies on HTMLAnchorElement to provide this information, and is suitable for most cases. In order to make urlUtils more accessible in the absence of DI, its methods were converted to standalone functions available globally. The urlUtils.resolve method was renamed urlResolve, and was refactored to only take 1 argument, url, and not the 2nd "parse" boolean. The method now always returns a parsed url. All places in code which previously wanted a string instead of a parsed url can now get the value from the href property of the returned object. Tests were also added to ensure IPv6 addresses were handled correctly. Closes angular#3533 Closes angular#2950 Closes angular#3249
jamesdaily
pushed a commit
to jamesdaily/angular.js
that referenced
this pull request
Jan 27, 2014
The location service, and other portions of the application, were relying on a complicated regular expression to get parts of a URL. But there is already a private urlUtils provider, which relies on HTMLAnchorElement to provide this information, and is suitable for most cases. In order to make urlUtils more accessible in the absence of DI, its methods were converted to standalone functions available globally. The urlUtils.resolve method was renamed urlResolve, and was refactored to only take 1 argument, url, and not the 2nd "parse" boolean. The method now always returns a parsed url. All places in code which previously wanted a string instead of a parsed url can now get the value from the href property of the returned object. Tests were also added to ensure IPv6 addresses were handled correctly. Closes angular#3533 Closes angular#2950 Closes angular#3249
jamesdaily
pushed a commit
to jamesdaily/angular.js
that referenced
this pull request
Jan 27, 2014
The location service, and other portions of the application, were relying on a complicated regular expression to get parts of a URL. But there is already a private urlUtils provider, which relies on HTMLAnchorElement to provide this information, and is suitable for most cases. In order to make urlUtils more accessible in the absence of DI, its methods were converted to standalone functions available globally. The urlUtils.resolve method was renamed urlResolve, and was refactored to only take 1 argument, url, and not the 2nd "parse" boolean. The method now always returns a parsed url. All places in code which previously wanted a string instead of a parsed url can now get the value from the href property of the returned object. Tests were also added to ensure IPv6 addresses were handled correctly. Closes angular#3533 Closes angular#2950 Closes angular#3249
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a small improvement to the regex SERVER_MATCH that will allow
angular to process urls with domain specific usernames and passwords
with hashbang like below:
http://domain&c5username:[email protected]/#home
Otherwise, a JS error occurs because regex doesn't match route and
framework doesn't execute request.