rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Geer <ch...@cxtsoftware.com>
Subject Re: Angular branch
Date Fri, 12 Apr 2013 17:24:34 GMT
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.

>
> > Chris
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message