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 > > > > > > > > > >
