On Mon, Apr 29, 2013 at 8:43 AM, Erin Noe-Payne <[email protected]>wrote:
> +1 for building on trunk and merging into branch - works for me. > > - What is the difference between organizations and groups? I couldn't > find any info looking through JIRA. > Groups are for security, Organizations are arbitrary items...like business units > - Mongodb and sql db's sort have a conflicting stance on > normalization, which might explain why they are currently treated as > properties. I generally agree that we should manage them separately > but it might be worth thinking through all the cases where we retrieve > a user and how often we would expect org / group info to come along > with it. > > On Mon, Apr 29, 2013 at 11:09 AM, Chris Geer <[email protected]> > wrote: > > On Mon, Apr 29, 2013 at 4:52 AM, Matt Franklin <[email protected] > >wrote: > > > >> On Fri, Apr 26, 2013 at 3:46 PM, Erin Noe-Payne < > [email protected] > >> >wrote: > >> > >> > Hey All, > >> > > >> > I added a few tickets last week for the new rest api routes. If anyone > >> > is available to help on the angular branch filling out the new rest > >> > apis that would be extremely helpful. In particular we need to > >> > continue implementing the pages api - most of this is just stubbed > >> > out at the moment. We will also need the users / authentication api > >> > soon. We do have the old rpc routes that give a lot of the crud > >> > functionality, but I don't want to spend too much time writing code to > >> > plug in to the json rpc responses if we can have decent rest endpoints > >> > in place. > >> > > >> > >> Since the APIs are functionally separate, I think we should work them in > >> trunk and merge them into the branch. I will hopefully have time to fix > >> the mongo issues for 0.21.1 today and can start the APIs later. Anyone > >> else have time? > >> > > > > I agree we should work on them in trunk and merge them back into the > > branch. I don't have time but I need to make time. I'll continue work on > > them this week. > > > > On that note, I went to create APIs for Organizations and Groups and > > realized there is no backend repository for either of those. They are > just > > attributes on person/user. My personal belief is that we should > > have separate management of both groups and organizations since those > > should really exist before a user, and have users assigned to them. Any > > objections? > > > > Chris > > > >> > >> > >> > > >> > Erin > >> > > >> > On Fri, Apr 12, 2013 at 1:58 PM, Erin Noe-Payne > >> > <[email protected]> wrote: > >> > > On Fri, Apr 12, 2013 at 1:24 PM, Chris Geer <[email protected]> > >> > wrote: > >> > >> On Fri, Apr 12, 2013 at 10:19 AM, Erin Noe-Payne > >> > >> <[email protected]>wrote: > >> > >> > >> > >>> On Fri, Apr 12, 2013 at 1:02 PM, Chris Geer < > [email protected]> > >> > wrote: > >> > >>> > On Fri, Apr 12, 2013 at 9:55 AM, Erin Noe-Payne < > >> > >>> [email protected]>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 > >> > >>> > >> > > >> >
