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.
Vitor_Santos
Posted 11 months ago·Last reply 11 months ago
4 comments
Vitor_Santos
OP11 months agoThanks 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!
Jason Hupka
·11 months agoMy 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.
Vitor_Santos
OP11 months agoI 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
·11 months agoWe 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.