Last post Jul 05, 2014 05:42 AM by francesco abbruzzese
Jul 03, 2014 10:29 PM|Rodrigo C|LINK
I am studying the possibility creating a SPA
My application is separated modules, and each user has permissions to certain modules
In Angularjs I not started, because when separated by module, each module possessed their own routes, which was bad for controlling access by user
I can a SPA using AngularJS routes with the server? This is bad practice?
How could solve?
Jul 04, 2014 07:47 AM|PatriceSc|LINK
You are not forced to use all features offered by a particular library. You could even use no library at all and still do an SPA page if you want.
But first, you may want to be more explicit about the problem you have. What is exactly the bad thing you saw with access control ? Ultimately I don't see how it is related with client side stuff. Access control is done at the server level anyway.
Jul 04, 2014 08:56 AM|Rodrigo C|LINK
configure the access routes in accordance with the user's permission
also the view buttons in menu with the user's permission
Jul 04, 2014 10:01 AM|PatriceSc|LINK
So basically the issue is rendering the proper client side markup depending on user permissions ? And yes, the template doesn't have to be a static HTML file. It could be a dynamic HTML markup file which is rendered based on whichever criteria you wish (such
as the user role).
Jul 05, 2014 05:42 AM|francesco abbruzzese|LINK
The best place where to verify user authorizations is the SPA component that Load the Views. In that place you may verify the required View against a set of access rules. Unlikely, in most of the more famous the only available hook is in the router (that
is involved just before the View loader), so you have to hook all routers(if you have several routers) in your applications.
Otherwise, you might implement your custom SPA View engine by using knockout.js. The forecoming release should have all needed module to build a SPA. Our custom SPA framework is knockout.js based and applies customizable "context rule" immediately before
loading a view. The default context rules verifies each View against authorization rules, and possibly load a complaint View or the login view instead of the required View.