search

tomquirk / linkedin-api

👨‍💼Linkedin API for Python
MIT License
1.71k stars 401 forks source link

CSRF check failed. #366

Open PitWD opened 5 months ago

PitWD commented 5 months ago

I was actually just using three functions.

api = Linkedin(username, password)
posts = api.get_profile_posts(public_id=user2scrap, post_count=5)
comments = api.get_post_comments(postID)

Everything was fine until yesterday... Cause I had no problems with your api, it's hard to say how things were looking on the api-side before the crash.

The login api = Linkedin(username, password) seems to function. If I print(api), I'll get <linkedin_api.linkedin.Linkedin object at 0x109c91730> with changing hex-numbers.

posts = api.get_profile_posts(public_id=user2scrap, post_count=5) crashes finally in the data = res.json() line of def get_profile(self, public_id=None, urn_id=None):, cause the call of res = self._fetch(f"/identity/profiles/{public_id or urn_id}/profileView") results in an CSRF check failed - at least I'm getting this error if I try to use the to fetch link, like https://www.linkedin.com/voyager/api/identity/profiles/abcUSERxyz/profileView, direct in a browser I'm logged in, too.

I'm on it to understand better how your lib/api is working to supply you with better information...

EDIT: OK, it seems to be a problem with MacOS - on Linux everything is fine... even I did the whole development on MacOS...

smullins998 commented 5 months ago

Having the same problem... Did you find any way to reconcile on MAC?

PitWD commented 5 months ago

Having the same problem... Did you find any way to reconcile on MAC?

On a fresh (linkedin_api was never installed before) M1 MacBook Air it's functioning fine. On the iMac i9 8-core, I had the CSRF problem with, it's still broken. Both MACs with Sonoma and all updates done. In around 24h I'll have acces to another "fresh" i5 iMac...

smullins998 commented 5 months ago

Having the same problem... Did you find any way to reconcile on MAC?

On a fresh (linkedin_api was never installed before) M1 MacBook Air it's functioning fine. On the iMac i9 8-core, I had the CSRF problem with, it's still broken. Both MACs with Sonoma and all updates done. In around 24h I'll have acces to another "fresh" i5 iMac...

@tomquirk wrote in the code that this may need to be fixed, but I'm not sure how so. Here is the "get_profile" function:

NOTE this still works for now, but will probably eventually have to be converted to

https://www.linkedin.com/voyager/api/identity/profiles/ACoAAAKT9JQBsH7LwKaE9Myay9WcX8OVGuDq9Uw

    res = self._fetch(f"/identity/profiles/{public_id or urn_id}/profileView")

The "res" variable returns a 999 response and the CSRF. I tried to uninstall and reinstall but no success

PitWD commented 5 months ago

I found this, too. And played a little with it. The problem is my i9 iMac. All other OS and other machines with MacOS are working without any problems. I expect, that there is somewhere just a corrupted file we would need to delete... I'm actually looking into this... but I'm in regular cases a BareMetal coder... OS and Browser/Net stuff isn't really mine...

PitWD commented 5 months ago

YES! It's just the cookie-file. In your home folder: .linkedin_api/cookies/bla@bla.jr delete the bla@bla.jr file - that's it.

I found that posibility of error while investigating the cookie-stuff in cookie_repository.py I'll look deeper into it - it seems an security issue for me, that the cokkie persists... but a manually delete is the actually fix.

smullins998 commented 5 months ago

YES! It's just the cookie-file. In your home folder: .linkedin_api/cookies/bla@bla.jr delete the bla@bla.jr file - that's it.

I found that posibility of error while investigating the cookie-stuff in cookie_repository.py I'll look deeper into it - it seems an security issue for me, that the cokkie persists... but a manually delete is the actually fix.

Great find. Working for me as well!

PitWD commented 5 months ago

As far I understand the whole cookie-thing... It's not an security issue! I also analyzed the cookies on Mac and Linux - even the broken one was theoretically valid. The validity check of the api only checks on DateTime. The order of the different cookies inside the *.jr file differs between MAC and Linux, but the types and time-ranges are simmilar. I have to fix another bug first - but I'll come back to the further investigation very soon.