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 Fri, 04 Oct 2013 18:16:50 GMT
Would relaying solve any of the security concerns? or wouldn't it just be
better to have the API exposed in Jetty and the console server calls use
the API but don't expose it directly?


On Thu, Oct 3, 2013 at 2:16 PM, Aaron McCurry <amccurry@gmail.com> wrote:

> For the Blur API relay I would suggest taking a look at a couple of
> classes.
>
> If you use:
> org.apache.blur.thrift.BlurClient
>
> Iface iface = BlurClient.getClient("controller1:40010,...");
>
> and then:
>
> org.apache.blur.thrift.ThriftBlurShardServer line 257
>  - context.addServlet(new ServletHolder(new TServlet(new
> Blur.Processor<Blur.Iface>(iface), new TJSONProtocol.Factory())), "/blur");
>
> This will add the servlet into a jetty server so that the "iface" variable
> can answer requests.
>
> I think this is all that's needed for the relay, assuming you have a jetty
> server setup.
>
> Aaron
>
>
>
> On Wed, Oct 2, 2013 at 8:10 PM, Vikrant Navalgund <
> vikrant.navalgund@gmail.com> wrote:
>
> > +1 For proxying Blur API calls via a Jetty server and relaying back the
> > data to the Client(Browser). With this approach we will have a clean
> > separation of the Client and the Blur API.
> >
> > Please let me know how to begin with the tasks.
> >
> > Regards,
> > Vikrant
> >
> >
> > On Thu, Oct 3, 2013 at 1:26 AM, Chris Rohr <rohr.chris@gmail.com> wrote:
> >
> > > 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*<
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > *Regards*,
> > *Vikrant Navalgund*
> >
>

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