ETOS SSE v2alpha #91
ETOS SSE v2alpha #91
Conversation
t-persson
requested review from
fredjn and
andmat900
and removed request for
a team
|
I recommend reviewing from this commit, to start: 28adb70 |
| var app *httprouter.Router | ||
| // Only load v2alpha if a public key exists. | ||
| if pub != nil { | ||
| authorizer, err := auth.NewAuthorizer(pub, nil) |
There was a problem hiding this comment.
I assume using nil works in this situation although it is kind of ambiguous what (as stated in the docs for New Authorizer) an empty []byte is, since var b []byte is not the same as b :=[]byte{}, although both could be considered an empty byte array.
There was a problem hiding this comment.
Any null value of byte works in this case. I.e. nil, var b []byte and b := []byte{} would all produce the same result
which is that the private key is ignored.
auth.go checks the len of the byte.
func main() {
var b []byte
fmt.Println(len(b)) // 0
b = []byte{}
fmt.Println(len(b)) // 0
b = nil
fmt.Println(len(b)) // 0
}
There was a problem hiding this comment.
Why isn't the public key handled in this file?
There was a problem hiding this comment.
It's handled in base since it can be used by serveral services for verifying signatures. The privatekey is only for signing which the keys service is responsible for
Applicable Issues
Not applicable, but I based this change on #89 since that made my config management easier.
Description of the Change
Add a SSE v2alpha.
SSE v2 will utilize RabbitMQ streams instead of polling the log listener container of the suite runner.
SSE v2 will have authentication for starting up new streams.
Added a new authorization service for creating and verifying tokens. Added these to the SSE v2alpha.
Added a new service for generating tokens. Shall be used by the ETOS client to generate a token to use for streaming SSE.
The authorization service and key service shall be used in the future for ETOS APIs.
I am aware of a few unfinished parts. This is intentional as I want to get eyes on this right now before continuing.
Alternate Designs
There are many. Considered kafka for a bit, but since we are already using RabbitMQ that seemed like a better choice.
Considered doing something that could listen to RabbitMQ and store messages in files that could be served to users. The complexity of this service was deemed too high.
I made the choice of creating one stream per SSE connection instead of having a single ETOS stream where we could filter out messages. According to "The Internet(tm)" RabbitMQ deals better with many small streams rather than one large and we hade some difficulty getting "Last-Event-ID" to work properly using a single stream.
Possible Drawbacks
We have not yet created a service for dealing with stream retention. Right now we will create all streams and never delete them. This must be fixed before v2.
Sign-off
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Signed-off-by: Tobias Persson [email protected]