Using the customized URL method is it possible to share a URL that implements the Escaped Fragment protocol?
For example a url in the following format:
https://www.example.com/#!/my-angularjs-page
So far from my experience, LinkedIn always removes the hashtag thus only retaining the domain name part of the URL:
https://www.example.com/
And therefore only the homepage is being shared.
References:
https://developer.linkedin.com/docs/share-on-linkedin
As of March 2016 the answer is no, LinkedIn share API customised URL method doesn't support hashbang URL's.
You need to escape the characters, whenever you want to use #, &, ?, and a few other reserved characters as the value of a GET parameter in a URL. It's called URL-encoding. The standard LinkedIn format is...
https://www.linkedin.com/sharing/share-offsite/?url={url}
So, for your site, notice how I am doing the encoding of these special characters...
https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.example.com%2F%23!%2Fmy-angularjs-page
# becomes %23. Afterall, how is the browser supposed to know that # there is for the URL you are sharing, or for the LinkedIn page itself? It needs to be able to distinguish, and it does that with encoding.
More Info: Official LinkedIn Share Documentation
Related
I'm trying to modularize my front-end which is in Angular-JS, with it we are using HA-proxy as a load balancer and K8s.
Each ACL in the HA-proxy configuration is attached to a different service in K8s and since we are using Angular with the (hash-bang enabled), in the HA-proxy configuration file we use that as a way to identify the different modules.
Below is my configuration, in HA-proxy which is failing because I can't escape the # in the file even after following the HA Documentation.
acl login-frontend path_beg /\#/login
use_backend login-frontend if login-frontend
acl elc-frontend path_beg /\#/elc
use_backend elc-frontend if elc-frontend
I have tried escaping it as /%23/login and /'#'/admin but without success.
Any idea would be greatly appreciated.
The fragment (everything followed by a # character) as defined in RFC 3986
As with any URI, use of a fragment identifier component does not
imply that a retrieval action will take place. A URI with a fragment
identifier may be used to refer to the secondary resource without any
implication that the primary resource is accessible or will ever be
accessed.
and it is used on the client side, therefore a client (a browser, a curl, ...) does not send it with a request. As reference: Is the URL fragment identifier sent to the server?
So there is no point to route/acl with it. The reason why haproxy provide an escape sequence for that is you may want to include it with a body, a custom header... but again, you will not obtain that part from the request line (the first line with URI).
What is really happening here is the user is requesting from HAProxy / and Angular, in the user's browser, is then parsing the #/logic and #/elc part to decide what to do next.
I ran into a similar problem with my Ember app. For SEO purposes I split out my "marketing" pages and my "app" pages.
I then mounted my Ember application at /app and had HAProxy route requests to the backend that serviced my Ember app. A request for "anything else" (i.e. /contact-us) was routed to the backend that handled marketing pages.
/app/* -> server1 (Ember pages)
/ -> server2 (static marketing pages)
Since I had some urls floating around out there on the web that still pointed to things like /#/login but really they should now be /app/#/login what I had to do was edit the index.html page being served by my marketing backend and add Javascript to that page that parsed the url. If it detected a /#/login it forced a redirect to /app/#/login instead.
I hope that helps you figure out how to accomplish the same for your Angular app.
In my application mvc 6, asp.net core and when I do the redirection the url in the browser appears to me as below, and the redirection does not happen.
http://localhost:46439/index.html#!/index#%2FInventory%2Fwarehouse%2Flist
url With special characters.
It adds '!' After the # and replace the '/' with '% 2F'
I do not know what the prolme exactly, since I use the visual studio IIS express 2015,
Can you help me please :)
Typically the #! (pronounced hash bang) followed by a path is used by browser based javascript code in single page apps to keep track of where in the single page app the user is.
Anything past the # will not affect which backend web page is requested if the url is sent to the backend web server. In the case of the url you provided that means that if this url were sent to the server, the page or route to respond would be
http://localhost:46439/index.html
Does that help?
Can you provide the code that you used to do the redirection?
I'm looking at various pages about dispatch.yaml, most of which contain similar information and examples:
https://cloud.google.com/appengine/docs/flexible/nodejs/how-requests-are-routed#routing_with_a_dispatch_file
https://cloud.google.com/appengine/docs/python/config/dispatchref
https://cloud.google.com/appengine/docs/go/config/dispatchref
etc.
I happen to be using node.js on GAE Flexible Environment, but I think it would be the same for every language and environment.
The problem is that these pages don't really specify how dispatch.yaml works. In particular:
Are rules applied in the order given? I'm assuming that the first matching rule is the one used, but nothing seems to say so.
Do leading glob (wildcard) characters match only the domain name, or could they match the first part of the URL's path? If the rule is */hello, would that match myapp.appspot.com/path/hello? I'm guessing not, based on some vague hints in the docs, but it isn't very clear.
If no rule in dispatch.yaml matches the URL, will it be routed to the default service? I would think it would have to, but again, these pages don't say.
Do URLs get rewritten based on the rules before they're sent to the service? If the rule is */path/* and the URL is https://myapp.appspot.com/path/hello, will the service see it as /path/hello or as /hello? I'm guessing the former.
I'm doing some trial and error now, so I may be able to answer my own question soon. I'm also submitting this to Google through their documentation feedback system.
Things I know so far:
Yes, rules are tried in order. So for example, if you want one URL to go to a specific service, and all other URLs to go to another service, you should specify the specific one first:
dispatch:
- url: "*/specific"
module: specific
- url: "*/*"
module: general
If you put those rules in the opposite order, module specific will never be used, because the URL /specific will be caught by the wildcard rule.
Unknown
Yes. You can test this by making a request not matching any dispatch.yaml rule and watching the default's service logs.
No rewriting. If the rule is */path/* and the actual URL is https://myapp.appspot.com/path/hello, your service should still handle /path/hello, not /hello.
Just to fill in the blank (feel free to paste this into the accepted answer):
No. It only matches the start of the path.
I created two apps with the following resources:
default -> /abc/def/test.html -> <h1>default</h1>
other -> /abc/def/test.html -> <h1>other</h1>
And 1 route:
<dispatch>
<url>*/def/*</url>
<module>other</module>
</dispatch>
When I hit {app engine}/abc/def/test.html I got "default"
I'm developing an application with webapp2 to be deployed on Google App Engine. URLs will always be preceded by a language identifier, such as:
http://www.mydomain.com/en/foo
http://www.mydomain.com/en/bar
I would like to automatically redirect any request that doesn't start with a language identifier to the corresponding English version. For example, the following URLs should redirect to the URLs above:
http://www.mydomain.com/foo
http://www.mydomain.com/bar
Currently, I'm using webapp2_extras to set up one redirect for every possible URL, which is creating a lot of code duplication. The problem is that, to my understanding, URL redirection in webapp2 needs to be defined on a per-handler basis.
How can I go about redirecting all requests that don't match a regular expression (language identifier in my case) to the corresponding modified URL (adding en/ in my case)?
what you are searching for is a middlware. here an example.
Old question but it seems like setting routes and catching exceptions would be a good way to go for this: http://webapp-improved.appspot.com/guide/exceptions.html#exceptions-in-the-wsgi-app
Routes for the http://www.mydomain.com/en/foo cases and any http://www.mydomain.com/foo cases will be a 404 exception, which you can address with a handler, redirecting to the appropriate "en" page.
I'm not aware of a solution for implementing custom persistent vanity URLs (my term, not sure if thats what they're really called) in DotNetNuke. Does anyone know of a solution? It can be configuring the core, using a third party module, or a suggestion of how to write it from scratch.
Here is what I'm thinking:
I want to point people to: http://mywebsite.com/awesome
I want the underlying URL to be http://mywebsite.com/genericpage.aspx?key=awesome&etc=etc
I don't want the URL to redirect. I want the user to see http://mywebsite.com/awesome only.
Essentially I'd envision an administrator being able to create these vanity URLs and specify what the vanity URL is and what the underlying URL is.
The closest thing, out of the box, is to define your friendly urls in SiteUrls.config found in the DotNetNuke root.
This way:
you point people to:
http://mywebsite.com/awesome.aspx
you have an underlying URL
http://mywebsite.com/Default.aspx?tabid=ID&etc=etc
users see:
http://mywebsite.com/awesome.aspx
Main restriction is that you will have an .aspx extension.
SiteUrl.config rules look like this:
<RewriterRule>
<LookFor>.*/awesome.aspx</LookFor>
<SendTo>~/default.aspx?tabid=ID&etc=etc</SendTo>
</RewriterRule>
Rewriter rule matches incoming url to a regular expression in the LookFor section, and sends it to an underlying url in the SendTo section. You need to be careful with the XML escape character '&' in the querystring parameters.
3rd party extensions like URL Master provide much more fine grained control, and you can have a global friendly url scheme based on page names, with or without .aspx extensions. Nevertheless, a simple "one url at a time" approach can be safer if you have custom modules with URL dependencies.
ActiveSocial supports these and I thought I saw something about support for this in Version 2.x of IFinity's URL Master, but I can't find anything on it now.