Open Danomophone opened 10 months ago
Whoops. Closed by mistake. It appears to me that when the request is made there is a field within the cookie that indicates the username of the requester. Not sure if spoofing this will make a difference, I will do some testing.
There is no indication in the returned JSON file with regards to the username of the requester and so it must occur at the time of the request rather than server side.
So it appears the session cookie moderates which items are returned - pretty sure it's _vinted_fr_session I had a play with the user id cookies remaining fixed and the fake item I made and hid would not return. Fair enough in that sense I suppose they want to hide these items from web crawlers, just a bit of a pain.
I am not the best at python but I will have a go at modding your code to see how brute forcing might work.
Well hello. Been a while, but, I revisited this. Firstly, brute force is impossible, there are just too many items. Even if a user loads two items at the same time there are like 3-400 items on average between them, and the site blocks requests after about 10,000 or so.
However, I have discovered the tag to return items in differing conditions.
In a request URL - https://www.vinted.com/api/v2/users/$userid/items?page=1&per_page=20&cond=$cond&order=relevance
Conditions can be sold, draft, hidden.
Now, I've done some messing around with cookies but I don't seem to be able to crack it - might be worth a look, there seems to be some general demand for this feature.
Yes, you're right to say that a URL like https://www.vinted.com/api/v2/users/$userid/items?page=1&per_page=20&cond=$cond&order=relevance will give you the sold items of a user, but after some tests, it gives you only the sold items if the user is you. For any other user, it will return the list of the items available for sale, not the sold ones. I've tested with users that I know they have sold items (because I've just bought something from them).
So it seems that, if you're not the logged in user, the cond
parameter is irrelevant and the list of items that is returned is the list of available items. This makes sense, since this matches the front-end: you can see your items that are available, sold, hidden, reserved, etc., but you can only see the available items.
From a developer's perspective, it's a good practice to have an API that doesn't offer more than what is strictly required by the front-end. So to me it's not shocking that you can't access the sold items of a user via the API if that doesn't match any feature in the front-end.
I've also done some testing with the catalog search feature, but I have not found a way to make the sold items appear (again, this is not shocking since the front-end doesn't offer this functionality).
So, apart from duplicating the Vinted database by scrapping regularly their site to catch new items and then see if they are sold or not, which is probably a big project, I'm afraid I have no idea on how to get the list of sold items for a user, but I will continue to think about it.
Yeah, understand. It's very likely to be something to do with the session cookies. I've tried making cookie v_uid (this is set to the logged in user ID) to another user but this doesn't work, so I am not sure exactly what this cookie does.
I don't have an efficient way to step through the backend code in terms of what it sends to the server but it sold items are most definitely still web facing, so surely there must be a way to return them based on userID.
All good, let me know what you come up with if anything :)
On Mon, Mar 11, 2024 at 3:18 AM Bruno Oberle @.***> wrote:
Yes, you're right to say that a URL like https://www.vinted.com/api/v2/users/$userid/items?page=1&per_page=20&cond=$cond&order=relevance will give you the sold items of a user, but after some tests, it gives you only the sold items if the user is you. For any other user, it will return the list of the items available for sale, not the sold ones. I've tested with users that I know they have sold items (because I've just bought something from them).
So it seems that, if you're not the logged in user, the cond parameter is irrelevant and the list of items that is returned is the list of available items. This makes sense, since this matches the front-end: you can see your items that are available, sold, hidden, reserved, etc., but you can only see the available items.
From a developer's perspective, it's a good practice to have an API that doesn't offer more than what is strictly required by the front-end. So to me it's not shocking that you can't access the sold items of a user via the API if that doesn't match any feature in the front-end.
I've also done some testing with the catalog search feature, but I have not found a way to make the sold items appear (again, this is not shocking since the front-end doesn't offer this functionality).
So, apart from duplicating the Vinted database by scrapping regularly their site to catch new items and then see if they are sold or not, which is probably a big project, I'm afraid I have no idea on how to get the list of sold items for a user, but I will continue to think about it.
— Reply to this email directly, view it on GitHub https://github.com/boberle/vinted-downloader/issues/2#issuecomment-1987291541, or unsubscribe https://github.com/notifications/unsubscribe-auth/BC5ICPQAS3VUCSVBMW375PTYXSFEVAVCNFSM6AAAAAA6AZTFZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGI4TCNJUGE . You are receiving this because you modified the open/close state.Message ID: @.***>
I have also had a look at the requests and headers for the items URL and it appears to me that it is the same get request with the same headers whether or not you are viewing your own profile or another users, which would imply that the hidden items are sent only if the actual user is logged in. It's not obvious to me how this mechanism would work as the user id doesn't seem to be sent in the GET request.
With that said we only buy with our account and so I do not have any sold items on the page to double check this.
You are correct and the element that indicates sold is "is_closed". I suppose if the item is closed it automatically has the is_visible element set to 0.
I've done a little playing and I think it would be possible and relatively easy to brute force the item numbers that still exist, are sold, and are related to the user, it but there are 10's of millions of item numbers and I would suggest doing this would result in an IP range ban 😄