Create createCard endpoint

[f1sh1918]

Is your feature request related to a problem? Please describe.
Create a new endpoint (or adjust existing one) that receive the user data from the self service portal

Describe the solution you'd like

• add a function that receives user data: Name, Aktenzeichen and Birthday
• Hash this data and check if the user is permitted or not
• if not permitted throw an error
• if permitted send the cardData (Name, Aktenzeichen, Birthday, StartDate, and the other general needed data)
• rate limiting: since this endpoint is not protected, it should be ensured that IPs with too many requests should be blocked, especially because the argon2id calculation is expensive.

Describe alternatives you've considered
We could extend the current createCard mutation and allow creating without jwt token if its a particular projectId (not sure if that is secure enough)

blocked by #1499

[seluianova]

rate limiting: since this endpoint is not protected, it should be ensured that IPs with too many requests should be blocked, especially because the argon2id calculation is expensive.

just got a sudden idea.
what if instead of a web form to issue a card, we create such form in the flutter app?
I believe this would solve the issue above and may also be more convenient for users because there would be no need to download and scan pdfs

[f1sh1918]

Its a good idea but we have lots of existing functionality in the "administration" like the card extensions, deeplinks which we can reuse. Further more we could also provide additionally a pdf if a service user supports a user that can not create the card by him/herself and just pass the pdf to him/her.

Normal use case is that the user doesn't have to scan or download the pdf but just create the card and then click a button with a custom_scheme deeplink which opens the app and activates the card.

Normal Process:

1. Open app -> Ausweisen Tab -> Beantragen
2. Form opens in browser
3. Type in information
4. Click create, button for card activation will appear
5. Click on Button opens the app and activates card

[seluianova]

@f1sh1918 is a no-way-but or to be discussed?

which we can reuse

is it bad if we won't have to? I assumed it could mean for us to do less, not more (or am I missing something?)

the card extensions

is it applicable to Koblenz? is it something that an unauthorized user does? (I'm not familiar with this process)

if a service user supports a user that can not create the card

is it a plausible case when the form has 3 fields?

Normal use case is that the user doesn't have to scan or download the pdf

right, but still an extra layer and extra browser interaction.

[seluianova]

is it bad if we won't have to? I assumed it could mean for us to do less, not more (or am I missing something?)

Just found an answer here #1430 and it seems to me that both actions could be potentially done through the app

[f1sh1918]

I think we discussed the process we gonna go with the customer. All projects have a separate "beantragen" function in the browser. Even in this case it wouldn't be as much effort as in the other cases to do that in the app we have to build a special case for Koblenz.
But anyway:

If we move the function in the app we can not easily use the pdf creation and we might need that as a backup. There will be people that won't be able to create their card by themselves.

Additionally we have an easy extendable card configuration in the administration where we already have All fields with validation except the referenceNumber which we can reuse. With my opened config pr you can already create a valid card f.e. You can just reuse that function in the Portal and adjust some small things.

The additional effort to move that to the native app is not that small if we build it generic and extendible. Create the input fields, make validation, show hints. Do the protobuf checks (sufficient space) before we send the data to card creation.

I would suggest to create an separate improvement issue. We might adjust that at a later point when there may be other customers with a similar creation process

#1430 will be done in the app yes but we don't need input fields because the data is already in the app

[f1sh1918]

Ah and one thing I forgot was that we should keep the possibility to create a static printed pass, therefore we need the pdfs

[seluianova]

Couple more questions:

1. Do we want to have a column userentitlements_id (or any-better-name) in the cards table?
2. Currently there is an issuer_id column, which refers to administrators table. Do we want to keep it empty for Koblenz or was there some other plan, like a dummy-user maybe?