incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Rohr <rohr.ch...@gmail.com>
Subject Re: Blur Console v2 Design Proposal
Date Wed, 02 Oct 2013 15:26:58 GMT
So as I have been getting into this more I am finding that using the
JavaScript API from the browser is not a good idea.  1. We will have to
deal with cross site scripting issues. 2. It will require the ENTIRE Blur
API to be exposed to browsers (potential security problem).  I think we
should just create calls in the Jetty Server that will make the calls to
Blur and return what is needed for the console.

I want to get one call built into my branch then I will push it up so I can
get help. (Hopefully today)

Thanks,
Chris

On Tuesday, October 1, 2013, Chris Rohr wrote:

> All,
>
> One thing I have found in looking at using the Javascript API is that we
> will need to make sure that the Blur Thrift server supports CORS
> (Cross-Origin Resource Sharing), this basically will allow us to get around
> the Same-Domain policy since most of our browsers will not be on the Blur
> box itself.  Do any of you know if the server is setup with that turned on?
>
> Thanks,
> Chris
>
>
> On Mon, Sep 30, 2013 at 8:38 PM, Vikrant Navalgund <
> vikrant.navalgund@gmail.com> wrote:
>
> Thank you Chris, that clears most of my doubts.
>
> Regards,
> Vikrant
> From: Chris Rohr
> Sent: 1/10/2013 2:29 AM
> To: blur-dev@incubator.apache.org
> Subject: Re: Blur Console v2 Design Proposal
> Vikrant,
>
> Thank you for your thoughts.  I will try to answer your questions here:
>
>    >>> What is this serving up? Is this a web service which would be
> consumed by the AngularJS front end. Since you mentioned that it would be a
> Jetty server(HTTP server + servlet container) a little clarification would
> be great.
>
> In my initial thoughts, all the Jetty server would be used for is to
> provide an HTTP server and serve up the static html pages.  All of the
> dynamic nature of the console would be done through Javascript using
> AngluarJS and the JS Blur API.  However, in the future if there is a need
> for functionality that can't be done from the Browser directly (i.e. User
> logins, zookeeper status, etc) then we could setup some basic JSON web
> service calls that would be served up by Jetty.
>
>    >>> Are we going to pull the information from within the
> Browser(something like AJAX) or the Jetty server would do a query to the
> Thrift service and pass it back to the Browser.
>
> We will be trying to use the JS Blur API to access Blur directly, however,
> we may run into Cross site scripting issues depending on how thrift works
> in JS and if that is the case then we would need to build proxies through
> the Jetty server.
>
>    >>> Since we will be using AngularJS and a Jetty server please clarify
> about not relying on a front-end and back-end component.  A typical
> scenario involving all the above 3 components would be helpful. This would
> also help us in figuring out the options we have while selecting the
> technology.
>
> Currently the console contains 2 pieces of software, a Ruby on Rails
> application (front-end) and a Java application (back-end).  The Java
> application handles all of the information collection in Blur (i.e. polling
> for statues, and tables, and queries) and stores everything in a database.
> The Ruby on Rails application presents all of the data in GUI form.  The
> Ruby on Rails application does have some direct access to Blur, but does
> not have direct communication to the Java application.  This proposal does
> away with the 2 separate pieces of code to 1. help simplify the logic and
> 2. help simply setup and startup of the console.
>
> I hope this answers your questions, please let me know if you think of any
> more.
>
> Chris
>
>
> On Mon, Sep 30, 2013 at 2:38 AM, Vikrant Navalgund <
> vikrant.navalgund@gmail.com> wrote:
>
> > Hello Chris,
> > Thanks for the writeup.
> > As a developer interested in contributing to the new BLUR console I have
> a
> > few questions.
> > Please ignore my lack of understanding of the architecture.
> > Treat me as a newbie to BLUR. My questions are inline.
> >
> >
> > On Mon, Sep 30, 2013 at 10:33 AM, Chris Rohr <rohr.chris@gmail.com>
> wrote:
> >
> > > All,
> > >
> > > As I have begun to start the next version of the console I wanted to
> give
> > > everyone my proposal for what should be in it and get any feedback that
> > you
> > > may have.  I have created a new branch (new-blur-console) and will be
> > > pushing it up as soon as I can.  Please let me know if you have any
> > > questions/opinions/suggestions about this proposal.  If I don't hear
> from
> > > anyone, I will just assume it looks good and I will move forward.
> > >
> > > Thanks in advance,
> > > Chris
> > >
> > > *Blur Console v2 Design Proposal*
> > >
> > > *Purpose*
> > >
> > > This writeup will help to determine what direction the console portion
> of
> > > Blur should go.  There has always been a need for a push button, easy
> > setup
> > > solution so that dev-ops could get up and running with the console
> > faster.
> > > *NOTE: *This is purely a suggestion and all opinions and
> recommendations
> > > are welcome.
> > >
> > >
> > > *Server*<
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message