It makes sense here. So we store the transaction events in the database now
and do not delete them even if they are completed totally.
I think it would be an issue if the transaction events become more and
more. is it possible to only store the in-flight transactions and move the
completed ones to the other backends ?

2018-02-03 14:27 GMT+08:00 Willem Jiang <willem.ji...@gmail.com>:

> Current we just need to provide a Restful service interface for the
> transaction event view. Customer can build their own UI on the top it.
>
> But for the omega and alpha communication, it's better to have the tenant
> and application id for supporting multiple user application and having an
> authentication check before the connection.
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
>           http://jnn.iteye.com  (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Feb 2, 2018 at 10:55 PM, Zheng Feng <zh.f...@gmail.com> wrote:
>
> > Does the user view the transaction events through the restful service of
> > the alpha server ? I think we need an authentication mechanism rather
> than
> > the tenant or application id.
> > The gPRC looks like to support the SSL/TLS.
> >
> > 2018-02-02 21:04 GMT+08:00 Willem Jiang <willem.ji...@gmail.com>:
> >
> > > Willem Jiang
> > >
> > > Blog: http://willemjiang.blogspot.com (English)
> > >           http://jnn.iteye.com  (Chinese)
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Fri, Feb 2, 2018 at 4:44 PM, Eric Lee <eric.lee....@gmail.com>
> wrote:
> > >
> > > > Currently, there are two known security concerns in Saga pack:
> > > >
> > > > *1. multi-tenants support*
> > > > When pack is deployed in a cluster, access to transaction events
> should
> > > be
> > > > limited to those have the corresponding permission. Without any
> > > > restrictions to that will cause chaos in the management of
> transaction
> > > > events and user can view all events pass through pack and have a peek
> > of
> > > > other transactions' flows which will be a serious security problem.
> > > >
> > >
> > > It's make sense that we add tenant or application id for separating
> > > transactions between two different application or users.
> > >
> > >
> > > >
> > > > *2. encrypted transportation between alpha and omega*
> > > > Currently, we use plain gRPC channel to communicate between alpha and
> > > > omega. However, when it comes to production environment, users may
> want
> > > > more secure transportation options. Settings of gRPC transportation
> > > should
> > > > be configurable.
> > > >
> > > > As alpha can invoke the  omega compensation operation, it's important
> > to
> > > make sure that omega connects to the right alpha server .
> > >
> > > >
> > > > We will solve the above security concerns ASAP in the next release.
> Any
> > > > solution to the above security concerns is welcome. Besides, are
> there
> > > any
> > > > other security concerns we miss? Welcome to point them out. Thanks.
> > > >
> > > >
> > > > Best Regards!
> > > > Eric Lee
> > > >
> > >
> >
>

Reply via email to