rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erin Noe-Payne <erin.noe.pa...@gmail.com>
Subject Re: Angular branch
Date Fri, 12 Apr 2013 17:58:24 GMT
On Fri, Apr 12, 2013 at 1:24 PM, Chris Geer <chris@cxtsoftware.com> wrote:
> On Fri, Apr 12, 2013 at 10:19 AM, Erin Noe-Payne
> <erin.noe.payne@gmail.com>wrote:
>> On Fri, Apr 12, 2013 at 1:02 PM, Chris Geer <chris@cxtsoftware.com> wrote:
>> > On Fri, Apr 12, 2013 at 9:55 AM, Erin Noe-Payne <
>> erin.noe.payne@gmail.com>wrote:
>> >
>> >> Hey all, I've pushed the first couple commits to the angular branch
>> >> with some extremely basic features in place. I want to start a
>> >> discussion to refine our vision for the portal application and keep
>> >> everyone on the same page.
>> >>
>> >> To preview the work so far:
>> >> - Check out from
>> https://svn.apache.org/repos/asf/rave/branches/angular/
>> >> - Spin up rave
>> >> - Hit the url http://localhost:8080/portal/app/angular/portal
>> >>
>> >> You should see some tabs that you can navigate between, some rendered
>> >> widgets. Very little else is working at this point.
>> >>
>> >> The proposal:
>> >> - An implementer should be able to define any custom context that they
>> >> want to present through the rave portal application. This corresponds
>> >> to the context as we discussed in the pages api [1]. Currently rave
>> >> ships with "portal" and "profile" contexts, and that's what I will be
>> >> building out.
>> >>
>> >> - Each context gets its own angular 'single-page' web application.
>> >> Moving within a context (IE /profile/erin -> /profile/matt) is all
>> >> client side routing & ajax calls. Moving between contexts (/profile
>> >> /portal) is a full page reload and entirely new angular webapp is
>> >> served. The reason for this structure is that each context will want
>> >> its own display (markup & css), its own routing rules, etc.
>> >>
>> >> - The contexts are served from one generic endpoint. Right now this is
>> >> /portal/app/angular/{context}/** to avoid collision with other
>> >> endpoints. Eventually I see this as moving to root and replacing most
>> >> of our current application endpoints. See
>> >> org.apache.rave.portal.web.controller.AngularController for the basic
>> >> implementation. The idea is that a call to the context endpoint will
>> >> always render the same basic view that imports the corresponding
>> >> context's markup and angular js app, and that app then handles any
>> >> further navigation / client side routing / importing of appropriate
>> >> resources.
>> >>
>> >> - In this way, the implementation of a context is entirely in static
>> >> files - html, css, js. If an implementer wants to add a new context
>> >> (say portfolio), they only need to create the new static files to
>> >> support that context. This means that a new context can be custom
>> >> built from the ground up without having to overlay and with complete
>> >> flexibility. However...
>> >>
>> >> - We can still write and provide reusable components. View partials
>> >> can be imported using angular's ng-include blocks, common services can
>> >> be written as angular modules.
>> >>
>> >> [1]
>> http://mail-archives.apache.org/mod_mbox/rave-dev/201303.mbox/browser
>> >
>> >
>> > I look forward to trying it out. Out of curiosity, have you put any
>> thought
>> > into how security will work? For example, can I restrict people to
>> > particular contexts? How will that work client side?
>> >
>> Definitely. So from the server side perspective we can continue to use
>> spring or whatever other security provider we want. We could force
>> someone to login before they can hit the {context} endpoint at all -
>> you'll see that is the case now but I don't really have an opinion on
>> that. I think where you put your security restrictions is on the api
>> endpoints that deliver data.
>> Then from the application perspective, any angular webapp that loads
>> in a particular context will need to make api calls to get data. You
>> can then write an http interceptor so that for any call that is
>> intercepted with a 401, some action is taken. There is a simple
>> example of this in the code right now in
>> script/angular-portal/routing.js lines 22- 41 (note you can't actually
>> see it in action because our endpoints don't return 401, and you have
>> to be logged in to see the context endpoint at all). This is a simple
>> implementation that assumes that if you receive a 401 you are simply
>> not logged in, and get redirected to a login page. But you can easily
>> take a more granular approach, and we can provide this as a pluggable
>> authentication service that each context webapp can configure and use
>> as they see fit.
> Ya, I'm curious to know how to handle it client side, I'm good with server
> side. Now that the server isn't rendering the pages, the client has to be
> aware of permissions so it can show/hide the correct information. For
> example, if a user doesn't have permission to view a certain page, the link
> should even be an option. That means there needs to be a way to have the UI
> get a list of all the permissions a user has and take those into
> consideration. I know there are ways to do it, just curious if you've put
> anything in place. Honestly right now the backend isn't really setup to
> handle that though. We need a more flexible permissions framework probably.
> We have the same problem in our system so on page load we cache all the
> permissions a user has client side and then the JS can use that list to
> make determinations.

This is a good question and honestly I only have a vague idea of what
it will look like. I think in this case your auth will need to be a
rest service. It will probably end up being part of the users api and
look something like the pages api with /api/users/@self.

>> > Chris

View raw message