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.
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. 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 >> > > >> >> > >> > > >> >> >> > > >> >> > > > >> > > > >> > > >> > >>
