search

opendevstack / ods-provisioning-app

Provisioning app, which triggers project and component provisions (including Jira / Confluence / BitBucket and OCP resource creation)
Apache License 2.0
15 stars 20 forks source link

Logging endpoint for SPA client errors #662

Open netzartist opened 3 years ago

netzartist commented 3 years ago

Followup to #634

As all kinds of errors which can happen in the SPA frontend are catched in Angular it's crucial that we collect most of them in the backend to monitor and get awareness of them. So a logging endpoint is needed in Spring Boot.

IMHO this is prerequisite task for switching to the new frontend layer as a default in ODS 4.

(In a next step in the Angular aop it should be possible to configure / (de)activate / toggle such a remote logging endpoint and create a service which "fire & forgets" the logs to such an URL.)

What are your thoughts /cc @michaelsauter

stitakis commented 3 years ago

First thoughts on this... yes, we can add an endpoint to be consumed by the SPA client to report errors. Once we receive the error we could decide if we log them, etc... (Also user usage could be pushed in this way using a different endpoint).

The question is how we want to secure this endpoint and authorize calls to it.

I see 2 scenarios: A. if the user was able to log in. Then I don't any problem. The endpoint could be consumed by the SPA client.

B. If the user didn't log in or was not able to do it (maybe because the SPA client is not working properly and there is an error to be reported), then we need to be more careful. For this scenario I think we need to design a solution that should not be easy to exploit by a DOS attack or something else.

michaelsauter commented 3 years ago

As discussed elsewhere, and to be completely honest, I see this as additional complexity that comes by using SPA for this thing. IMHO not ideal and a sign of over-engineering. I would refrain from making this too complicated. I propose to start with scenario A as outlined by @stitakis, and not care about scenario B for now. When a user is unable to authenticate, I would log to the browser console (support can help then by looking at the console logs together with the affected user).