You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Which forces connection renegotiation which causes OCSP to be checked.
Reportedly when using LDAP backed automatic cert enrollment revoking a user from the web UI will also reset their connection. If we can do the same via the TAKServer REST api it would be grand.
See also #48 for working around the issue (also since in 4.x WebTAK does not check OCSP we might need to do that anyway).
The text was updated successfully, but these errors were encountered:
If the client connected recently the reset might not drop them since TAKServer seems to cache OCSP responses for a while (which is a perfectly valid thing to do). So putting them into a separate group that does not see anything could help with that too.
We can force client connection reset by first getting the "subscriptionUid" from GET "/Marti/api/subscriptions/all" and then disconnect using DELETE "/Marti/api/subscriptions/delete/${subscriptionUid}"
But.. There is something fucky going on under the hood and the removed user can still connect using winTAK as long the winTAK hasn't been restarted. The user can keep the connection open even after running the the DELETE query to api, which seems to force the connection reset to some degree. The new connections end up being in the ANON group instead of the tak_default group.
Which forces connection renegotiation which causes OCSP to be checked.
Reportedly when using LDAP backed automatic cert enrollment revoking a user from the web UI will also reset their connection. If we can do the same via the TAKServer REST api it would be grand.
See also #48 for working around the issue (also since in 4.x WebTAK does not check OCSP we might need to do that anyway).
The text was updated successfully, but these errors were encountered: