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: [Discuss] Rave & Angular strategy
Date Mon, 10 Jun 2013 17:03:06 GMT
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 <m.ben.franklin@gmail.com> wrote:
> On Fri, Jun 7, 2013 at 5:57 PM, Chris Geer <chris@cxtsoftware.com> wrote:
>
>> On Fri, Jun 7, 2013 at 2:46 PM, Matt Franklin <m.ben.franklin@gmail.com
>> >wrote:
>>
>> > On Fri, Jun 7, 2013 at 4:58 PM, Chris Geer <chris@cxtsoftware.com>
>> wrote:
>> >
>> > > On Wed, Jun 5, 2013 at 2:41 PM, Chris Geer <chris@cxtsoftware.com>
>> > wrote:
>> > >
>> > > > On Wed, Jun 5, 2013 at 2:21 PM, Erin Noe-Payne <
>> > erin.noe.payne@gmail.com
>> > > >wrote:
>> > > >
>> > > >> On Wed, Jun 5, 2013 at 4:49 PM, Matt Franklin <
>> > m.ben.franklin@gmail.com
>> > > >
>> > > >> wrote:
>> > > >> > On Wed, Jun 5, 2013 at 12:53 PM, Chris Geer <
>> chris@cxtsoftware.com>
>> > > >> wrote:
>> > > >> >
>> > > >> >> On Wed, Jun 5, 2013 at 9:06 AM, Erin Noe-Payne <
>> > > >> erin.noe.payne@gmail.com
>> > > >> >> >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
>> > > >> >> >
>> > > >> >>
>> > > >>
>> > > >
>> > > >
>> > >
>> >
>>

Mime
View raw message