I load user profile informations from instagram by the basic api in a local test app.
So this actually works like written in the documentations.
I used Postman to get along the authentication and token stuff.
The order to access the graph api, to query media fields would be like:
Get access code (from authentication window redirect url)
Get access token (from acces_token endpoint)
Get media data (from graph api by access_token)
I´m using UI5 js framework with UI5 Tooling.
I get a response with data in step 3 from ajax call, but first i have to execute step 1 and step 2 manually.
But i want to do all this authentication-mechanism directly in my app. Including opening this authentication window and acessing the code from the redirect url.
When i do an ajax call in step 1, i get an CORS error of course, because step 1 doesnt respond with the corresponding CORS header (like step 3 does).
Well, anyways i most likely could handle this by a proxy, but whats about the production environment? I dont get how this approach should ever work in a real app. Even when the CORS problems are handled by aproxy in dev environment, it should be still there when a real user uses the app.
So the question is: How can i access or implement this authentication window (on a diffrent origin) in my app? I have seen other apps doing this permission window, but i have no clue how to implement it in a web app.
By clicking "Allow" you get redirected to he redirect_url with the access code
How can i get the access code directly in my app, avoiding CORS in production
I don't have a definite answer, but regarding your CORS issue: It seems like instagram added a CORS policy somewhere last year (see this other question on SO). This means that you would indeed have to build a proxy.
Basically you need something that accepts all the endpoints that the original API accepts, forwards them to instagram, reads the response, and returns the response to the client (aka browser). But your proxy will then not add the CORS headers. Or even better, you add your own CORS headers (assuming your proxy and your app will run on the same server) and no one else will be able to use your proxy from their web app.
Unfortunately I don't know about this authentication window. Maybe this is just a fancy way to hide that they are running a proxy behind the scenes as well? You should be able to see in the network tab where the insta data is coming from after you login. I would guess not directly from their graph API.
I'm developing an app using the PhoneGap API but the problem is it takes over the 'View' property of Laravel.
The other problem is the index file must be .html so i'm unsure of how to secure user requests. Usually I would have the csrf meta tag in the header but in this case I am unable to save the csrf_token() in the meta tag as PHP can't run in the HTML file.
I was thinking maybe something like cookies would be best to secure the requests to the different routes (post/get requests) but am still quite unsure of how I would achieve this.
The general functionality of my phone application would be making use of POST and GET methods which retrieve and add data to the controllers (i.e. Signing a user up)
What are the different options I could make use of to secure my application requests using Javascript/HTML as a connection to Laravel Controllers?
Did you try with api_token? Actually app requests need not to be csrf protected once you authenticate api requests via api_token. Generate an unique api_token for each of your user. Wrap your api routes with api middleware. Append this token in every api request via GET parameter / Authorization header / as an auth password.
This article might be helpful. How touse API tokens for authentication in Laravel
I have a JSP webapp developed in Eclipse as a dynamic web project.
we use a third party web application that invokes my application, I need to validate that only the requests that come from that application are allowed to create a new session in my application.
I´m tring to do it with javascript and thinking , as a last resource, to use a Filter class to know the request origin and define the behaviour.
the problem is that the user requires that the operation is done on the client side, meaning I have to use javascript or similar, I have read about document.referrer on JS, but so far nothing is shown on the console.
Anything that you do in the client using JS for handling sessions wouldn't be secure as it can be easily modified by a malicious user. Also, using the referer or any other http header params would be insecure as they can also be easily spoofed.
If this third party application is directly calling your application I imagine that you have some degree of control over it. Can you access and modify its source code or are you just using configuration params?
Ideally the third party application would use an authentication token on each request that it makes to your application. And these authentication requests as well as all the session handling logic would always be handled on the server side.
I'm creating an AngularJS application that uses the JWT token for authentication. The token is being passed using the AngularJS interceptor as shown below.
'request': function(config)
{
if (store.get('jwt_token') != null)
{
config.headers['x-access-token'] = store.get('jwt_token');
}
else
{
config.headers['x-access-token'] = '';
}
return config;
}
Whenever I'm accessing any /restricted pages, everything is working fine. The issue is when I'm going to the /restricted page by directly typing the URL in the address bar (or refreshing the page), the AngularJS gets circumvented, and hence, the Interceptors don't intercept the request, and the token is not passed.
I've been searching for a while, I found some solutions like responding with a piece of code that loads the AngularJS then makes a redirect from there. However, I'm looking for a simpler/neater approach if possible as I might be missing something here.
I can detect if the request came from AngularJS or not by checking for the x-access-token since I'm always passing it (empty value if user is not authenticated).
Solution
Alex's answer is pointing to the exact problem, thanks Alex.
I finally figured it out yesterday. The solution I went with was to make sure all the requests come from AngularJS, I have a list of the restricted pages, if any of them is requested, I'm calling a function to verify and validate the JWT token on server side, if it's valid, proceed, otherwise, go to login page. The key thing is to ensure that ALL requests should go to the index.html to make sure AngularJS is handling the routing.
This link helped me greatly to solve this issue.
http://arthur.gonigberg.com/2013/06/29/angularjs-role-based-auth/
It sounds as if there's a confusion between Angular's router and server endpoints.
You are presumably triggering the $http configuration while navigating through the application, using URL's tracked by Angular's router (which works fine), whereas the /restricted URLs are server URLs.
Therefore, when you ask for anything /restricted outside of the Angular app (in the browser), it is sending the request straight to the server, and not via the Angular router or application.
Basically, you need to create routes in your Angular app that are within the restricted context, that when initialized, run the $http configuration. You should never be calling server end-points directly in the address bar, except for index.html (/).
I'd suggest having an Angular route called /restricted-area so that when a user hits it, it will always use the $http methods you have, by being a dedicated Angular route, calling the server's /restricted endpoint internally, via a controller.
I had asked the similar question 2 months ago. What I have understood is, normally before javascript frontend frameworks how the http request were served was:
We type a url in address bar.
The browser sends the request.
The server gets the request.
serves the necessary html, js and css files.
browser renders it.
But as the recent shift to various javascript frontend frameworks and use of RESTful api.s has begun, the request needs to have authorization header. Thus in many of the single page web apps with javascript frameworks like angularjs,
the initial request for '/' router is sent
the server serves the web application to your browser
all the further routing in the web application is done within your front end application, hence the "#" after your url.
Requests are made by the application to fetch, update, delete or post from your application through angular js.
So when you make request from angular application. Your request is intercepted from angular application and intercepted by your interceptor. However when you enter the url from your address bar, the browser sends request directly to server, because at that point of the request, the browser has not loaded your angular web application.
What I suggest is you set html5mode to false and put a # before your route.
like localhost/#/restricted and do the routing from your route provider. When there is # before your route, the request for / goes to server, your application loads, and make some controller in /restricted from your application make http request to desired server end point. In this way the request is sent through your application and will be intercepted by your interceptor. The refresh and directly typing the address in address bar works as well.
I assume if you access the page /restricted your Angular app will start up correctly and it is just a login problem.
If you don't have a token then you have to redirect to the login page. You could show the login as a modal overlay then you don't have to switch the page. The interceptor will monitor the response result for status 401. In that case the interceptor will show the login. After the successful login the interceptor will execute the origin request - with the token.
You can find a working example in the angular app
just pass this token in cookies, not in header.
I would like to consume two remote REST services (which I don´t have control over) from my AngularJS app.
Service 1: To authenticate myself by passing the credentials as form-data in the HTTP header using POST verb.
Service 2: To get the data in JSON format by using GET verb.
Using the $http or $ngResource leads to same error message in Chrome Developer console:
OPTIONS http://remote.service.com
net::ERR_EMPTY_RESPONSE
Example on $http GET
$http.get('http://remote.service.com').
success(function(data) {
$scope.greeting = data;
});
I believe this is because of XSS limitations in JavaScript? I have considered solutions like CORS (requires control over the remote service) and JSONP (only GET) but none of these will solve my problem so Im seeking tip on other solutions.
What I don´t fully understand is why calls to the very same services works fine when using REST Client Plug-in in Chrome (for instance POSTMAN) from my local machine.
Im running Express and NodeJS in the backend, if that might help.
In stead of calling the remote REST service directly from the frontend app (AngularJS app), call the backend service within same origin and from backend do the remote service call (as a proxy). This solves this issue.