Sander, You suggest that the state should live in its own service (agreed) and that you can write your own decorator to check that:
Well, the state of a user should live in a service. You can check that > state easily in the components using the canActivate hook. And indeed, > writing a small decorator that does that is a good way to handle it. > That decorator can even wrap in a existing canActivate > Do you have an example of this? From what we've tried there is no way to get to the App-level Injector to get the proper instance of your service(s) from within a decorator. There is also a @CanActivate decorator in angulr2, but we can't see how you would access your services from it. I don't see how that decorator can be useful if you have no access to service instances. Thank you On Friday, January 8, 2016 at 12:57:30 PM UTC-5, Brian Troncone wrote: > > 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.
