On Mon, Jun 10, 2013 at 1:03 PM, Erin Noe-Payne <[email protected]>wrote:
> Matt, I don't entirely follow the authentication piece. What do you > mean that the login form is hosted by the api server? My thought is > that each context, if it needs to be behind authentication, will > implement an authentication http interceptor so that any data requests > that fail due to a 401 will redirect to the login form. Rave should > ship a generic login form with each context able to override with a > custom implementation. The login form can post to a validation > endpoint that returns an api key for making requests going forward. > In essence, this is what I am suggesting; but, rather than specifically tie it to a context, we will want to be able to support multiple contexts from the same API server. The biggest difference is using OAuth 2 implicit flow for API authorization. It will act much like an API key (authorization token); but, uses the OAuth 2 protocol to manage TTL & authentication. > > I agree that user management, widget store and admin will all end up > being separate from the "context" system. I figured we would end up > writing these out as angular apps as well. > +1. They are less critical; but, we should make sure we are using consistent UI frameworks. > > On Fri, Jun 7, 2013 at 6:31 PM, Matt Franklin <[email protected]> > wrote: > > On Fri, Jun 7, 2013 at 5:57 PM, Chris Geer <[email protected]> > wrote: > > > >> On Fri, Jun 7, 2013 at 2:46 PM, Matt Franklin <[email protected] > >> >wrote: > >> > >> > On Fri, Jun 7, 2013 at 4:58 PM, Chris Geer <[email protected]> > >> wrote: > >> > > >> > > On Wed, Jun 5, 2013 at 2:41 PM, Chris Geer <[email protected]> > >> > wrote: > >> > > > >> > > > On Wed, Jun 5, 2013 at 2:21 PM, Erin Noe-Payne < > >> > [email protected] > >> > > >wrote: > >> > > > > >> > > >> On Wed, Jun 5, 2013 at 4:49 PM, Matt Franklin < > >> > [email protected] > >> > > > > >> > > >> wrote: > >> > > >> > On Wed, Jun 5, 2013 at 12:53 PM, Chris Geer < > >> [email protected]> > >> > > >> wrote: > >> > > >> > > >> > > >> >> On Wed, Jun 5, 2013 at 9:06 AM, Erin Noe-Payne < > >> > > >> [email protected] > >> > > >> >> >wrote: > >> > > >> >> > >> > > >> >> > Hey All, > >> > > >> >> > > >> > > >> >> > Over the last couple months I have been working in the > angular > >> > > branch > >> > > >> >> > to develop a strategy for updating rave portal to function > as a > >> > > more > >> > > >> >> > flexible application that delivers the same current > >> functionality > >> > > out > >> > > >> >> > of the box, but provides a more generic model for extension > and > >> > > >> >> > treatment of new contexts. I want to outline that vision > here > >> and > >> > > try > >> > > >> >> > to describe what it would mean to develop in rave under this > >> > > >> paradigm. > >> > > >> >> > This would mean breaking changes for future versions of > rave, > >> so > >> > I > >> > > >> >> > want feedback. Would this make sense for how you use rave? > >> What's > >> > > >> >> > good, what's bad? > >> > > >> >> > > >> > > >> >> > The proposal: > >> > > >> >> > > >> > > >> >> > - The server deals entirely in data through rest api's. > >> Anything > >> > > that > >> > > >> >> > the rave portal ui currently does should be accessible & > >> > modifiable > >> > > >> >> > through a rest api. > >> > > >> >> > > >> > > >> >> > >> > > >> >> +1 - my only concern right now is security. Rave doesn't have > a > >> > very > >> > > >> robust > >> > > >> >> security model right now as there is really only User and > Admin. > >> I > >> > > >> think we > >> > > >> >> need to expand this to include groups (we can use the existing > >> > groups > >> > > >> as > >> > > >> >> those aren't even used anywhere) and some security based on > >> > friends. > >> > > >> >> > >> > > >> > > >> > > >> > This should be enforced via the API, so we should be able to > grow > >> > out > >> > > >> the > >> > > >> > security model there. Right now it is very model oriented > with, > >> as > >> > > you > >> > > >> > note, the only two roles being defined as user & admin. > >> > > >> > > >> > > >> > >> > > >> To be honest I'm not super familiar with what the current > security > >> > > >> model looks like. But from the perspective of writing angular > >> > > >> applications that consume the api, my expectations would be: > >> > > >> > >> > > >> - I have restful endpoints to login and logout > >> > > >> - Every request I make against the api will correctly return 401 > or > >> > > >> 403 status codes if there is any authentication problem. > >> > > >> - My app can then intercept these codes and properly redirect > the UI > >> > > >> to login page / not authorized warning. > >> > > >> > >> > > > > >> > > > Erin, yes, from the UI perspective that is a pretty good > viewpoint. > >> > From > >> > > > the server perspective though there is some more thought that is > >> > needed. > >> > > > For example, should every user on system be able to get all the > >> > > attributes > >> > > > about every person? Should a friend be able to see more details > than > >> > > > another random person? The server needs to be able to have a model > >> > where > >> > > > decisions can be made on more than just is this person a normal > user > >> or > >> > > an > >> > > > admin. The UI also needs to be able to handle that as well. For > >> > example, > >> > > is > >> > > > you aren't frieds with someone certain fields may come back as > null. > >> > Not > >> > > a > >> > > > huge deal but a consideration. > >> > > > > >> > > > The reason security is so important on the server side is once you > >> move > >> > > > the UI to the client side you can no longer trust the client side > >> > because > >> > > > there is no guarantee that the request is coming from our client. > At > >> > > least > >> > > > with the JSP model we could count of the view filtering data if > >> needed, > >> > > now > >> > > > we have to do it in the web services directly. > >> > > > > >> > > > >> > > To reply to myself here....moving to a web service model, what > >> > > authentication approach were you planning on using? Since we'll be > >> > > deprecating the form based authentication, will we just move to > basic > >> > > authentication? > >> > > > >> > > >> > I am not sure deprecating the login form makes a ton of sense from the > >> OOTB > >> > portal. I think it should be easily replaceable; but, it is nice to > have > >> > the user management/login from the OOTB perspective. I would imagine > >> that > >> > the User login /management section of rave is configured as the URL > that > >> > the users are directed to login at. > >> > > >> > >> There will still need to be a login form, just housed in angular I would > >> assume. Which means there needs to be a way to authenticate users that > >> angular can call as a web service that doesn't require posting a form. > In > >> addition to that, there needs to be a way to call the web services > without > >> using the UI at all which means OOTB there should be a non-form way of > >> authenticating users. > >> > > > > The login form should be eventually angular; but, should be hosted on the > > API server. We can then use OAuth Implicit Grant for the client JS and > > regular authorization grant for server-to-server. If a deployment uses > SSO > > or other authentication means that doesn't require a login form, it > doesn't > > have to deploy that UI. > > > > In general, I think the auth form, user management, widget store & > > administration UIs become decoupled from the main application delivery UI > > (and each other). > > > > > >> > >> > > >> > > >> > > > >> > > > > >> > > > Chris > >> > > > > >> > > >> > >> > > >> > > >> > > >> >> > >> > > >> >> > > >> > > >> >> > - No more jsp's. Probably no more server-side view > composition > >> at > >> > > >> all. > >> > > >> >> > The views are served entirely as static files - html, js, > css - > >> > and > >> > > >> >> > composition and routing are handled client-side via > angular.js > >> > > >> >> > > >> > > >> >> > >> > > >> >> +1 - What I want to know is can I run an angular based gadget > >> > inside > >> > > >> the > >> > > >> >> angular based Rave? Does that even make sense, and is there > >> anyway > >> > > >> >> to optimize it? > >> > > >> >> > >> > > >> >> > > >> > > >> >> > - Rave ships with a portal and a profile context. Each > context > >> > > >> >> > represents a workspace and has complete ownership of its own > >> > > >> branding, > >> > > >> >> > navigation, etc. If you want to add a new context X it > should > >> > > involve > >> > > >> >> > no overlay, just extension. > >> > > >> >> > -- In terms of data, you will simply add new pages with a > >> context > >> > > of > >> > > >> >> > X, and the api will deliver them. > >> > > >> >> > -- In terms of ui and routing, the portal application has a > >> > > wildcard > >> > > >> >> > endpoint that looks like "/{context}/**". Out of the box, > >> > {context} > >> > > >> >> > will be matched against a directory at > static/html/{context}. > >> So > >> > > you > >> > > >> >> > just add static/html/X. This will serve up an angularjs > >> > single-page > >> > > >> >> > app that displays its own ui, manages its own routing etc. > This > >> > > gives > >> > > >> >> > us complete flexibility and customizability for any new > >> context. > >> > > >> Also, > >> > > >> >> > because the static content is simply being served from a > url, > >> it > >> > > >> could > >> > > >> >> > just as easily be coming from a cms or another server as > from > >> the > >> > > >> >> > portal's static directory. > >> > > >> >> > > >> > > >> >> > >> > > >> >> +0 - I guess I still don't fully understand the whole context > >> > concept > >> > > >> so I > >> > > >> >> just need to look into it more. > >> > > >> >> > >> > > >> > > >> > > >> > A context to me is just a workspace that allows you to define a > >> > > specific > >> > > >> > function that the UI is to perform. From there the data model > of > >> > Rave > >> > > >> is > >> > > >> > used to manage widgets within the construct of the context. > For > >> > > >> instance, > >> > > >> > profile & portal are contexts. You could also have group, > >> project, > >> > > >> site, > >> > > >> > organization or other top level contexts. > >> > > >> > > >> > > >> > > >> > > >> >> > >> > > >> >> > > >> > > >> >> > - To support that flexibility but still stay DRY, view > >> components > >> > > (in > >> > > >> >> > angular-speak that is directives and templates, which are > >> roughly > >> > > >> >> > analogous to jsp tags) will be modular and re-usable. So > >> > components > >> > > >> >> > that we provide in the out of the box contexts like > navigation > >> or > >> > > >> >> > widget chrome should be directives that can be require()'d > and > >> > > >> re-used > >> > > >> >> > by your new custom context. Likewise you should be able to > >> write > >> > > and > >> > > >> >> > share any custom directives between your various contexts. > >> > > >> >> > > >> > > >> >> > >> > > >> >> +1 > >> > > >> >> > >> > > >> >> > > >> > > >> >> > - To knit everything together I think we will need an AMD > >> script > >> > > >> loader, > >> > > >> >> > probably require.js. This would allow your custom context to > >> > easily > >> > > >> >> > build out a dependency tree, get the features it needs for > its > >> > > >> context > >> > > >> >> > without any extra weight, and to optimize / concat / minify > >> > > resources > >> > > >> >> > for each context. > >> > > >> >> > > >> > > >> >> > >> > > >> >> +0 - If it's needed get it. > >> > > >> >> > >> > > >> > > >> > > >> > There is a very nice performance benefit to using an AMD > loader, > >> > > >> especially > >> > > >> > if we have a strong set of lifecycle events in the application. > >> It > >> > > >> should > >> > > >> > allow us to start initializing widgets earlier and make a > >> "snappier" > >> > > UI. > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> >> > >> > > >> >> > > >> > > >> >> > Let me know what you think. > >> > > >> >> > Thanks, > >> > > >> >> > Erin > >> > > >> >> > > >> > > >> >> > >> > > >> > >> > > > > >> > > > > >> > > > >> > > >> >
