Martin, Thanks for your reply. We did something similar by setting a static on the service to an instance of itself when constructed. As you said though, this sort of thing is hideous and breaks DI so I'm really hoping Sander can instruct us on a better solution, or one in the works. I completely agree that this should not be handled at the component level for large applications.
On Friday, January 8, 2016 at 12:39:09 PM UTC-5, Martin Wawrusch wrote: > > I worked around the 1 and 2 problem with the services by using a global > variable being set in the constructor of the services needed, - UGLY as > hell and completely defeats the purpose of DI, but works for the time > being. > > That said I very much agree with you that security is a cross cutting > concern that should not be handled at the component level for larger apps. > One angular 1 dashboard app that we have has 124 routable components - > that's a lot of CanActivates right there... > > > On Friday, January 8, 2016 at 9:21:13 AM UTC-8, Brian Troncone wrote: >> >> Sander, >> >> One example use-case shows itself in a business application I am >> building, which requires role based authentication throughout the >> navigation structure. For example, each user is only allowed access to >> certain sections of the site after they authenticate. The active user's >> roles are stored in an Angular 2 service. I am not sure how to best >> accomplish a valid role check based on the methods you suggest. Some things >> I have tried: >> >> 1.) Creating a custom 'Authenticate' decorator to check logged in user's >> roles v. valid roles passed to decorator. The problem is there is no way to >> access the app-wide injector outside a component, therefore I cannot obtain >> the correct instance of my service containing the current users roles. >> >> 2.) Using @CanActivate, I have not found a way to gain access to the >> correct application services, similar to problem described in #1. If you do >> not have access to services here, how useful is this method? >> >> 3.) Subscribe to hooks in higher-level component which encapsulates the >> remaining application components. I am not sure the best method to >> accomplish this because my entire application needs these checks performed >> at every route change and I am only current using 1 'router-outlet'. >> >> Any advice or insight you can give on this issue would be greatly >> appreciated. I feel this is a scenario many business applications will >> encounter and it would be good to know a suggested 'best practice' for >> solving this problem. Thanks in advance! >> >> On Tuesday, December 22, 2015 at 9:56:17 AM UTC-5, Sander Elias wrote: >>> >>> Hi Martin, >>> >>> No, you shouldn't need to inject it everywhere. Usually there is no need >>> for that. If you make sure that at a higher-level component the check is >>> done. >>> See, for the router your app has a tree-like structure. You can put an >>> can(de)activate on every branch, and/or even at the base. everything above >>> that point, can only be reached when the condition is satisfied. >>> >>> Can you provide a use-case that really demands a global handler? >>> >>> Regards >>> Sander >>> >> -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
