Compatibility with Vapor 4 implementation

[kevinrmblr]

Hi there!

I've been working on a server reference implementation based in the Swagger file. I'd love your help with testing and keeping it compatible moving forward.

It can be found here: https://github.com/kevinrmblr/traceprivately-server

There's some open ends, such as limits on updating daily keys and updating the related data, but mostly it should be ready:

• It saves the form fields (as plain text) alongside the batch
• Saves the risk level
• Calls support both plan JSON and MessagePack

I also left room to submit data in the auth call, so a token can be added, like a PushToken or a DeviceId token. Depending on the app setup, it'll either require this or also accept an empty body (which is currently the default to be compatible with the iOS app), an auth body could look like this:

{
	"strategy": "IOS_DEVICE_ID",
	"token": "SOMETOKEN"
}

Let me know your thoughts!

[HendX]

Hey @kevinrmblr - this is great! I will link to it from the README.

In regards to auth - the auth call in the iOS app can submit data as required. The protocol KeyServerAuthentication allows for this (with a couple of example implementations).

Any yea, it submits in the same way as you've described. Please see see KeyServerAuthentication.swift.

[kevinrmblr]

Hi there, thanks for the info. As far as I can see, it can either post a body with a key of either:'receipt' or 'token'. The former would be a push token and the latter a DeviceID token.

Would you be up for adding a strategy field (or some other name)? Then it'll be a bit easier to identify which authentication method is used, especially if a server allows more than one. Then both push-token and deviceid-token can share the same token key.

[HendX]

It’s loosely defined because I think there’s still scope for this to change somewhat. Realistically the publisher or the app and server will customise this as necessary.

Perhaps the prebuilt Auth modules can include a strategy field rather than requiring it. I think that’s worthwhile doing, especially to help debug/setup the app and server.

[HendX]

@kevinrmblr I've added a t parameter to the requests which indicates the method used for authentication. It's defined by the specific auth module and is optional, so any custom implementations don't need to use it.

See 0a43678

[kevinrmblr]

Hi @HendX, thanks!

I see there's an identifier t, that currently can be either dc or asr, ill update the server to mimic that!