Normally a client sends the notificationAddress and notificationType parameters with each registration and authentication response as HTTP POST parameters. In some situations however a tiqr client can not get a notification address. Different clients respond (and have responded) differently to this situation. The notificationAddress and notificationType parameters may be absent, or both or only notificationAddress maybe set to the string "(null)" or "NULL". This leads to several issues that this PR addresses:
Currently there are user entries in the user storage table that have notificationAddress set to '(null)' or 'NULL'. Stepup-tiqr tries to send a push notification to these addresses, and that leads to an error. We change this behaviour so that NULL or (null) means no push address / type so no notification is send. We explicitly log this situation.
When a client omits a notificationAddress or notificationType this currently leads to an exception and the registration will fail. We change this behaviour so that this is accepted and allow the registration and authentication to continue.
Normally a client sends the notificationAddress and notificationType parameters with each registration and authentication response as HTTP POST parameters. In some situations however a tiqr client can not get a notification address. Different clients respond (and have responded) differently to this situation. The notificationAddress and notificationType parameters may be absent, or both or only notificationAddress maybe set to the string "(null)" or "NULL". This leads to several issues that this PR addresses:
Currently there are user entries in the user storage table that have notificationAddress set to '(null)' or 'NULL'. Stepup-tiqr tries to send a push notification to these addresses, and that leads to an error. We change this behaviour so that NULL or (null) means no push address / type so no notification is send. We explicitly log this situation.
When a client omits a notificationAddress or notificationType this currently leads to an exception and the registration will fail. We change this behaviour so that this is accepted and allow the registration and authentication to continue.