Forum Discussion

Vitor_Santos's avatar
2 months ago

Log Ingesting API - Anyone having issues?

Hello,

I've been facing issues with the logs ingestion API recently.

To make it simple, I'm just trying to ingest a simple test message (no device correlation, etc.) & it always returns status 401.


Tried via Postaman, Bash, Python, Powershell, from several sources (including my own laptop which has 0 FW restrictions).

I know the user account needs to have Manage permissions at the Logs piece & it has indeed.


I've tried with the portal admin already. This is bugging me as I'm not understanding why this isn't working & I would like to understand if others are facing the same.

I've raised a internal support case already, but, no luck so far.

4 Replies

  • My philosophy has been "If I can do it with a bearer token, then I will use that" because I have found the LMv1 security model to be effective, but fragile, to work with because of how the auth tokens are created.

    For a thing like a log ingestion API depending on a bearer token, just create your own bearer-token-rotation policy.

  • Thanks for the feedback guys!

    Yeah, I ended up using Bearer & will rotate it periodically. 

    Was just curious to know if the LMv1 was sunset or no on this API endpoints, since I haven't found any "official" documentation regarding that.

    Thank you!

  • I was able to make this work using the Bearer token. But, via LMv1 token it doesn't (using the regular access_id/access_token).

    • Joe_Williams's avatar
      Joe_Williams
      Icon for Professor rankProfessor

      We had a similar issue and as jhupka​ stated we ended up moving to the bearer token model.

      Our issue tho ultimately was that the time was off on the device sending the log. So then the LMv1 token was generated improperly.