rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Franklin <m.ben.frank...@gmail.com>
Subject Re: [Discuss] Rave & Angular strategy
Date Mon, 10 Jun 2013 18:37:11 GMT
On Mon, Jun 10, 2013 at 1:03 PM, Erin Noe-Payne <erin.noe.payne@gmail.com>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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message