I'm developing a web application with Aurelia. I had a problem with Aurelia and Whatwg-fetch.
The API's relative url is api/post/load/{id}. When I use the fetch client to call this API, I think it gets the current url to call (http://localhost:9000/detail/api/post/load/{id}). I don't know why it happens. Sometime it calls the API's url correctly, other times it does not.
The url at which you access your app is http://localhost:9000/details. Since you didn't include a hashmark (#) in it, I assume the details part is not added by Aurelia, which leads me to believe that you access the app itself at /details.
If that is the case, the problem is that by not prefixing your API's url with a slash (/), the resulting url will be base url+api url, that is, localhost:9000/details + api/post/load/id. The slash between details and api is added on your behalf while constucting the final absolute url. In this case, all you need to do is to prefix the api url with a slash, like so: /api/post/load/{id}.
Related
I am using 'omniauth-linkedin-oauth2'.
When I am login with linkedin then I am getting this error
Invalid redirect_uri. This value must match a URL registered with the API Key.
This is my settings:
Went back to LinkedIn developer site (https://www.linkedin.com/secure/developer ) to check my setting again. Everything matches API Key, Secret Key and OAuth 2.0 Redirect URLs.
Searched web looking for some clues. Couldn’t find a one. Crazy issue:
Then I saw that in the URL Owin was appending some extra string to the redirect_uri “signin-linkedin”. When I decoded the URL I saw this http://localhost:54307/signin-linkedin . I took this URL and placed it in the OAuth 2.0 Redirect URLs field in the LinkedIn developer site.
This link is helpful for me
https://naveengopisetty.wordpress.com/2014/09/15/linkedin-oauth-2-0-issue-invalid-redirect_uri-this-value-must-match-a-url-registered-with-the-api-key/
You can just look in url that you are getting that error message on.
eg. if you are using python's social auth the url would look like this:
https://www.linkedin.com/uas/oauth2/authorization?scope=r_basicprofile+r_emailaddress&state=XXXXXX&redirect_uri=http://example.com.au/sa/complete/linkedin-oauth2/&response_type=code&client_id=YYYYYYY
so you would use this part of the above url for the redirect url
http://example.com/sa/complete/linkedin-oauth2/
please check your redirect_url. for my case I see like this.
https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=77k93y0w31zaey&redirect_uri=http%3A%2F%2Flocalhost%3A1729%2Fsignin-linkedin&scope=r_basicprofile%2Cr_emailaddress&state=nhAC-nR-CgEwO3XS2ezANhuPBMz-IUmLPJYgGHlZvZ8B1pCfsGBU0PR0dZ5XxE4zbyeI0RLcKByqPLKkgQdqMm4s6DjFYqMCEehYA2iWT9MfioEHjPXGCt2USxUTF0wKBpflCUjG5URVlJa3qI7U3ydFOErZ4Hhnr9SVmKdf1bithYfbOqBx345o8LQLexbddQ687vP6y0szrIyCM6FHip1tCpOY3Hgg5FJQEFH1mCJ_yLunD5vDUN4VVfkQbcjk
for this I add the url for OAuth 2.0 Authorized Redirect URLs:
http://localhost:1729/signin-linkedin
where http://localhost:1729 =base url and
signin-linkedin = the string which add after base url
One more solution is to just verify the client_id you've been using the whole time..because with every update in the list of redirect_uri, the client_id gets updated.
Worth mentioning when one uses libraries to handle oauth: some libraries fail to care about the protocol that is used (or at least require further parametrization). Eg, I gave Linkedin https://example/callback as oauth2 url, but the library sent the request with http://example/callback as parameter.
I had this when trying to authorise from a zurb Reveal modal popup. In my case, the issue was the URL for the page that was being displayed in the popup was not in my OAuth2 Redirect URLs list on the LinkedIn developer site.
That was easy to miss because the page URL from the page in the modal is not the URL that was currently showing in the browser's address bar. Once I added the URL for the page being shown in the pop up it worked.
After spending hours i finally get to the solution. You got an error no issues just check the url and find redirect_uri. Copy and Paste it's value it in your linkedin dev account oauth2 redirect field.
Make sure to add both with and without trailing '/' as redirect url.
http://localhost:8000/oauth/complete/linkedin-oauth2
http://localhost:8000/oauth/complete/linkedin-oauth2/
I have an HTML5 app written in static html/js/css (it's actually written in Dart, but compiles down to javascript). I'm serving the application files via CDN, with the REST api hosted on a separate domain. The app uses client-side routing, so as the user goes about using the app, the url might change to be something like http://www.myapp.com/categories. The problem is, if the user refreshes the page, it results in a 404.
Are there any CDN's that would allow me to create a rule that, if the user requests a page that is a valid client-side route, it would just return the (in my case) client.html page?
More detailed explanation/example
The static files for my web app are stored on S3 and served via Amazon's CloudFront CDN. There is a single HTML file that bootstraps the application, client.html. This is the default file served when visiting the domain root, so if you go to www.mysite.com the browser is actually served www.mysite.com/client.html.
The web app uses client-side routing. Once the app loads and the user starts navigating, the URL is updated. These urls don't actually exist on the CDN. For example, if the user wanted to browse widgets, she would click a button, client-side routing would display the "widgets" view, and the browser's url would update to www.mysite.com/widgets/browse. On the CDN, /widgets/browse doesn't actually exist, so if the user hits the refresh button on the browser, they get a 404.
My question is whether or not any CDNs support looking at the request URI and rewriting it. So, I could see a request for /widgets/browse and rewrite it to /client.html. That way, the application would be served instead of returning a 404.
I realize there are other solutions to this problem, namely placing a server in front of the CDN, but it's less ideal.
I do this using CloudFront, but I use my own server running Apache to accomplish this. I realize you're using a server with Amazon, but since you didn't specify that you're restricted to that, I figured I'd answer with how to accomplish what you're looking to do anyway.
It's pretty simple. Any time you query something that isn't already in the cache on CloudFront, or exists in the Cache but is expired, CloudFront goes back to your web server asking it to serve up the content. At this point, you have total control over the request. I use the mod_rewrite in Apache to capture the request, then determine what content I'm going to serve depending on the request. In fact, there isn't a single file (spare one php script) on my server, yet cloudfront believes there are thousands. Pretty sure url rewriting is standard on most web servers, I can only confirm on lighttp and apache from my own experience though.
More Info
All you're doing here is just telling your server to rewrite incoming requests in order to satisfy them. This would not be considered a proxy or anything of the sort.
The flow of content between your app and your server, with cloudfront in between is like this:
appRequest->cloudFront
if cloudFront has file, return data to user without asking your server
for the file.
If cloudFront DOESN'T have the file (or it has expired), go back to
the origin server and ask it for a new copy to cache.
So basically, what is happening in your situation is this:
A)app->ask cloudfront for url cloud front doesn't have
B)cloudfront
then asks your source server for the file
C)file doesn't exist there,
so the server tells cloudFront to go fly a kite
D)cloudFront comes back empty handed and makes your app 404
E)app crashes and
burns, users run away and use something else.
So, all you're doing with mod_rewrite is telling your server how it can re-interpret certain formatted requests and act accordingly. You could point all .jpg requests to point to singleImage.jpg, then have your app ask for:
www.mydomain.com/image3.jpg
www.mydomain.com/naughtystuff.jpg
Neither of those images even have to exist on your server. Apache would just honor the request by sending back singleImage.jpg. But as far as cloudfront or your app is concerned, those are two different files residing at two different unique places on the server.
Hope this clears it up.
http://httpd.apache.org/docs/current/mod/mod_rewrite.html
I think you are using the URL structure in a wrong way. the path which is defined by forward slashes is supposed to bring you to a specific resource, in your example client.html. However, for routing beyond that point (within that resource) you should make use of the # - as is done in many javascript frameworks. This should tell your router what the state of the resource (your html page or app) is. if there are other resources referenced, e.g. images, then you should provide different paths for them which would go through the CDN.
I have noticed that GET requests for nonexistent paths don't return a 404 response. Instead, the client gets a "200 Ok", AngularJS renders the main view, and rewrites the path to /. A request for a nonsense URI is logged as successful in the server logs. If I understand correctly, the problem is that since AngularJS handles routing, the server has to accept a GET request for any URI and always respond by serving the client side of the app ("200 Ok" or "304 Not Modified").
For example, using the project scaffolded by the angular-fullstack Yeoman generator, requesting a nonexistent /unicorn goes like this:
GET /unicorn 200 31ms - 3.29kb
GET /partials/main 304 36ms
GET /api/awesomeThings 304 5ms
The Express route that handles the request looks like this:
// server, last route:
app.get('*', controllers.index);
// controllers:
exports.index = function(req, res) {
res.render('index');
};
and index.jade is the root of the whole client side of the app.
After a quick look at the server side code of other AngularJS / Express projects on Github (AngularJS Express seed, AngularJS login), I see that this is a common pattern. I am wondering if there is a better way to handle requests for nonexistent paths, so that the client gets a real HTTP 404 response?
The angular documentation has a section about the routing. Also, this question and this question have some information that pertains to IIS but could easily be adapted to express.
Html link rewriting
When you use HTML5 history API mode, you will need different links in different browsers, but all you have to do is specify regular URL links, such as: link
When a user clicks on this link,
In a legacy browser, the URL changes to /index.html#!/some?foo=bar
In a modern browser, the URL changes to /some?foo=bar
In cases like the following, links are not rewritten; instead, the browser will perform a full page reload to the original link.
Links that contain target element
Example: link
Absolute links that go to a different domain
Example: link
Links starting with '/' that lead to a different base path when base is defined
Example: link
When running Angular in the root of a domain, along side perhaps a normal application in the same directory, the "otherwise" route handler will try to handle all the URLs, including ones that map to static files.
To prevent this, you can set your base href for the app to <base href="."> and then prefix links to URLs that should be handled with .. Now, links to locations, which are not to be routed by Angular, are not prefixed with . and will not be intercepted by the otherwise rule in your $routeProvider.
Server side
Using this mode requires URL rewriting on server side, basically you have to rewrite all your links to entry point of your application (e.g. index.html)
You can use $route.otherwise() function
In order to decide what to do with undefined
Routes.
If you want to still show a 404 message,
You could simply set a /404.html route both in this Function and in express.
This is actually express handling routing--not angular. Remove the app.get('*', ... that you found to disable that.
I am developing an application that will serve multiple customer-organizations, each of them should be given access based on a fixed url. Example: domain/myapp/CustomerOrg1
Previously I always registered a new WAComponent-subclass for each of these entry-points. That does work but there has to be a better solution, I would like a single component-class to find out which URL the request uses (to then respond with the customer-org's homepage)
I tried:
registering a WARequestHandler-subclass; and it allows me to find out the full path (incl. /CustomerOrg1) but I am outside of any session and don't know how to get into one.
registering a WAComponent-subclass as /myapp, and it works in that it also handles /myapp/CustomerOrg1 automatically, however when I try to find out the URL used (by self session url inspect) it claims to be only the base-url (/myapp).
Try
self requestContext request uri
and if you are not in a component but any object you can do
WACurrentRequestContext value request uri
Please be aware that the uri you get in the answer by Norbert is in a production environment a value that has already been processed, and possibly modified, by your (Apache/nginx/etc) webserver responsible for static content and load balancing.
We have a service located at a url like services.example.com/123456/*. We'd like to provide that same service at a url like www.example.com. The original service is provided by a PaaS provider which doesn't work with custom domains.
We want a request to go something like this: browser requests www.example.com/path, we tell it to go to services.example.com/123456/path, and it gets the data from there, but treats the response as if it came from www.example.com/path - so doesn't update document.location or the url at the top, and treats links as relative to the original path.
Is this possible, or would we have to have a own proxy-like website?
You need a proxy that do url rewriting.