In that function, I can get current controller and route value and according to current angular controller and route will call API which will return if user has access to that particular method or not.
I already did at server side using authorization attribute but need at client side.
Since you have not provided any code example. I assume you have routing in the client side. And you want authentication/authorization during the routing process.
To do this you can observe the route before route started changing and can check the authenticity of the user there and permit or refuse the user accordingly.
Sample code:
var app = angular.module('app', []);
app.run(function($rootScope) {
$rootScope.$on("$locationChangeStart", function(event, next, current) {
// check here the user's authenticity and let the user go or redirect to another page
});
});
Related
I am using Auth0 in my AngularJS 1.x.x app.
The way I have the app set up is by using div ng-if="isAuthenticated" to display (and hide) div's in my templates. However, I want to be able to prevent API calls in my controllers if the user is not authenticated. What is the correct syntax to block those calls?
I think I'm looking for something like:
if (isAuthenticated) {
ServerRequest.getAllPatients({
}).then(function(resp){
$scope.myTestData = resp
}).catch(function(err){
console.log(err);
});
} else { alert("you are not logged in") }
It depends on the exact requirements but in general you would have an Angular service that keeps track if the user is authenticated or not and the you inject this service wherever you need to apply conditional logic based of the authentication status.
Another possibility would be to completely reject the navigation to certain routes if those routes require an authenticated user and there isn't one. You could check this article for some guidance (Deal with users authentication in an AngularJS web app).
I am trying to deal with authentication with ui-router and angularJS, i would like to achieve this normal scenario where:
if (user is not authenticated && state requires authentication) then
go to 'login' state
else if (user is authenticated && state does not require authentication) then
go to 'main' state
else go to state requested by the user.
i have implemented it in a way i am not sure is correct and i need some validation here from you guys.
I have a resolve function that retrieving the information whether user is authenticated from the server, if it rejected, then I send the user to 'login' state in $stateChangeError. if it resolved I handle the other logic in $stateChangeSuccess.
But as I understand that the information would only be available in $stateChangeSuccess and not in $stateChangeStart , therefore if I implement the logic i wrote above in $stateChangeSucceess then some of the pages will flicker before the transition ends.
Please advise. Is there another way or a way to improve this solution ?. I thought of making a resolve function for each state , check if the user is authenticated and make the routing there.
Thanks.
This is a problem with single page apps. One of the solutions that I use in my angular pages is to cache the userid and the fact that the user is authenticated in local storage. You can add an expiry to this as well. Here's a link to the local storage module: https://github.com/grevory/angular-local-storage (there are others too).
Then in each state you can check to see if the user has already been authenticated rather than going back to the server each time. Also, this will help the back/fwd buttons work better. Typically in your controller you'd have code to check if the user is authenticated (which would probably go and check local storage for a flag and get the userinfo which was initially retrieved from the server).
I can see some security issues with this though if the browser is being shared by multiple users.
This article seems to list a better/newer way to do this: https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
using runfunction in your module combining with a service that knows if the user it's authenticated:
angular
.module('myApp')
.run(runFn);
runFn.$inject = ['$rootScope', 'MyAuthService', '$state'];
function runFn($rootScope, MyAuthService, $state){
$rootScope.$on('$stateChangeSuccess', function(e, toState, toParams, fromState, fromParams) {
var userAuthenticated = MyAuthService.isLogged();
//* check if the user it's present on cookies
//if(!userAuthenticated && $cookieStore.get('user_token'))
// If the token is in the cookies i get the user from server
//else
// $state.go('login')
//your logic here
/*if (user is not authenticated && state requires authentication) then $state.go('login')*/
});
}
This function will be executed always that a state change.
I'm trying to get my head around where authentication logic should live in my application, the approach I am trying to take is to have any auth responsibility handled by the server, redirecting to a login page that's separate from the main client side app - which I think is sensible?
I have an angularjs application which uses ui-router and makes api requests which are routed via the server.
I am using an Express server which is configured to use a couple of directories like so:
app.use(express.static('./dist/client'));
app.use(express.static('public'));
I then have middleware that performs an auth check (Im using express-session as well) and redirecting to login when required.
//A request to '/login' will serve the login page
app.use('/login', function(req, res){
res.sendFile(path.join(__dirname+'/public/login.html'))
});
//This will listen for all requests
app.use(function(req, res, next) {
if (req.url!== '/auth/login' && !req.session.accessToken) {
res.redirect('/login');
return;
}
next();
});
On initial page load, when no session cookie exists, express immediately redirects to the login view as expected.
After logon, and the main application loads, if I then manually delete the cookie in the browser and perform a state change that requires an api request (in a state resolve), the server returns the login view but this gets rendered inside the ui-view component being used by ui-router, rather than a full redirect to /login by the server.
Also, if I navigate to a page (after deleting cookie) that does not perform an api request, that page is served back, I guess as its not covered by my app.use middleware that does the redirect.
I feel I'm missing something obvious here, can someone help me please?
One way to handle this, there are others:
Make the API server return a 401 (unauthorized) error if the user is not authenticated, rather than redirecting them to the login page.
Then, in a run block, add a $stateChangeError event handler to the $rootScope. This way, if an API request is made from an unauthenticated user, it will trigger the event handler. From there you can redirect the user to your login page:
angular.module('myApp').run(function($rootScope, $window) {
$rootScope.$on('$stateChangeError', function() {
$window.location.href = '/login';
});
});
I'm not sure if it makes sense to worry about the other scenario where you delete the cookie and navigate to a page that does not make any API requests. What is such a user going to gain? In this hypothetical scenario, they are already looking at a page in your app (that might have sensitive data or not). How did they get there to begin with?
You could use a similar event handler for the $stateChangeStart event that checks for the presence of the cookie and redirect if it's missing. But, you don't want to put code in your client that validates the cookie, b/c then any curious visitor could read that code and learn how to create a cookie to fool your server.
I am trying to authenticate users of my Firebase (Angularfire) app with Facebook Login.
Everything works as expected when I authenticate with a pop-up window, but to support as many browsers as possible (Chrome on iOS doesn't support pop-ups, for e.g.) I want to fallback to authenticating with a redirect ($authWithOAuthRedirect).
I have confirmed my setting in Facebook are correct (my app ID and secret, for e.g.) but when I am redirected back to my app after Facebook authenticating with a redirect, $onAuth fires but I don't have my Facebook authData.
Instead, I have anonymous authData. For a bit of background; all users are authenticated anonymously if they are not otherwise authenticated (with Facebook, in this e.g.).
I can't see to find why this would be - the user should now be authenticated with Facebook, and have the Facebook authData.
Excepts of my code are below for some context:
Triggered when a user clicks the login button
function logIn () {
firebaseAuth
.$authWithOAuthRedirect('facebook', function (error) {
if (error) {
console.log(error);
}
});
}
$onAuth (inside my Angular app's run)
function run ($rootScope, firebaseAuth, sessionStore) {
$rootScope
.$on('$routeChangeError', function (event, next, prev, error) {
if (error === 'AUTH_REQUIRED') {
console.log(error);
}
});
$rootScope
.$on('$routeChangeSuccess', function (event, current, prev) {
$rootScope.title = current.$$route.title;
});
firebaseAuth
.$onAuth(onAuth);
function onAuth (authData) {
console.log(authData);
}
}
Route resolver to otherwise anonymously authenticates users
function sessionState ($q, firebaseAuth) {
var deferred = $q.defer();
firebaseAuth
.$requireAuth()
.then(deferred.resolve, guest);
return deferred.promise;
function guest () {
firebaseAuth
.$authAnonymously()
.then(deferred.resolve, rejected);
}
function rejected () {
deferred.reject('AUTH_REQUIRED');
}
}
The route resolver (sessionState) checks to see if the user is authenticated already, and if not, tries to anonymously authenticate them.
After the Facebook authentication redirect, the user will already be authenticated, and therefore does not need to be anonymously authenticated.
But, it appears that they are? As $onAuth logs the authData to the console, and it is anonymous.
Any help with this would be much appreciated! I am sure it has something to do with my route resolver, as pop-up authentication works fine (the route is already resolved).
EDIT: I tried completely removing my route resolver in case it was that causing an issue, but it made no difference. The user was just 'unauthenticated' instead of being either authenticated with Facebook (after $authWithOAuthRedirect) or anonymously.
UPDATE: I tried authenticating with Twitter and the redirect transport and I have encountered the exact same problem. I have also tried using port 80, instead of port 3000 that my app was being served on locally, but no joy.
UPDATE: When I turn off html5Mode mode in my app - and routes now begin with #s - $authWithOAuthRedirect works perfectly. From this I can only assume that $authWithOAuthRedirect does not support AngularJS's html5Mode. Can anyone confirm this is an issue, or do I need to change my code to support html5Mode and authWithOAuthRedirect?
EXAMPLE REPO Here is an example repo demonstrating the problem: https://github.com/jonathonoates/myapp
Look in the dist directory - you should be able to download this and run the app to reproduce the problem. In scripts/main.js is the app's JS; I've added a couple of comments but it's pretty self explanatory.
To reproduce the problem: click on the 'Facebook Login' button, and you'll be redirected to Facebook to authenticate. FB will redirect you back to the app, but here lies the problem - you won't be authenticated, and the returned authData will be null - you'll see this in the console
UPDATE: When I add a hashPrefix in html5Mode e.g.
$locationProvider
.html5Mode(true)
.hashPrefix('!');
The app works as I would expect - authenticating with Facebook and the redirect transport works.
Couple of niggles though:
The URL has #%3F appended to it, and is available/visible in the browser's history.
This would rewrite URLs with #! in browsers that do not support History.pushState (html5Mode), and some less advanced search engines might look for a HTML fragment because of the 'hashbang'.
I'll look into highjacking the URL upon being redirected back from Facebook instead of using hashPrefix. In the URL there is a __firebase_request_key which may be significant e.g.
http://localhost:3000/#%3F&__firebase_request_key=
It looks like this is indeed an incompatibility between Firebase and AngularJS's html5mode as you suspected. At the end of the redirect flow, Firebase was leaving the URL as "http://.../#?", and Angular apparently doesn't like that so it did a redirect to "http://.../" This redirect interrupts Firebase (the page reloads while we're trying to auth against the backend) and so it is unable to complete the authentication process.
I've made an experimental fix that ensures we revert the URL to http://.../#" at the end of the redirect flow, which Angular is happy with, thus preventing the problematic redirect. You can grab it here if you like: https://mike-shared.firebaseapp.com/firebase.js
I'll make sure this fix gets into the next version of the JS client. You can keep an eye on our changelog to see when it is released.
My use case:
User is already logged in automatically server side using Facebook with laravel and Socialite.
I check if the user exists in the db and if not create it and log them into laravel.
Then I need to start an Angular app and make sure they are logged in with Laravel / Facebook.
After reading this article, it looks like this token based approach is what I should take.
In the tutorial you serve a login form with Angular, and then pass the email and password to an authenticate controller (Laravel), which returns a token (create by JWT-Auth).
Once the token is in Angular all is well, my problem is that I want to get the token directly into Angular without a login form since the user is already logged in as mention above.
I'm wondering if I could just output the token in markup somewhere and then pick it up from Angular or would that somehow be a security risk? I guess people will only be able to view source and see their own token?
If this is the wrong way to do this, then how should I do it? Do I need to authenticate with Facebook with Javascript, and then create a new laravel user with ajax?
Thanks so much!
One approach you could take is to add something to your .config block that checks for the presence of a JWT in local storage and if there isn't one there, makes a request to the API to see if the user is logged in on the Laravel side. If the user is logged in, a JWT is returned which can be picked up and saved in local storage. Since the .config block is run when the Angular app loads, this will only happen once, which is probably what you're looking for.
Here's what that might look like. First the Laravel side:
// AuthenticateController.php
...
// Simulates a user being logged in on the Laravel side through something
// other than credentials sent from the front-end. Obviously you would use
// Socialite
public function authenticate()
{
$user = User::find(1);
$token = JWTAuth::fromUser(1);
return response()->json(compact('token'));
}
...
Then the Angular:
// app.js
...
.run(function($rootScope, $state, $auth) {
if(!$auth.isAuthenticated()) {
// No credentials provided because the user is already logged in on the server
$auth.login().then(function() {
$state.go('users');
}
}
$rootScope.$on('$stateChangeStart', function(event, toState) {
...
This would just run when the Angular app loads, which will be after your user has logged in with Socialite. It's essentially just checking whether there is a user logged in on the back end and if so, the token is retrieved. It's a bit hacky and the interface isn't obvious, so it might not be the best solution.
You would need to arrange your authenticate controller on the Laravel side such that it returns the token if the user has logged in via socialite or require credentials if he/she hasn't (which is the traditional login).
You could also look at this approach to see if it works for you: https://github.com/barooney/jot-bot/tree/socialite
Let me know if that works out!