https://api.metacpan.org/user sometimes returns {} for logged in users.

[oalders]

@ranguard, @rwstauner and @grantm have all confirmed that the /user endpoint returns an empty hashref for them. @grantm reported that he got data after re-logging in to metacpan. The cog icon was visble to all (I believe) at the point when they were getting no data.

On a related note, it looks like it always returns {} if the URL is not under SSL, so maybe we should return a helpful message under plain HTTP.

[rwstauner]

like the others I have not logged out/in in a long time...
as in not since we moved to the bytemark server,
and i don't know... maybe even since The Great Reindex,
either of which might be acceptable reasons for such behavior.

[rwstauner]

While my /user is still {} it doesn't seem to keep me from marking new dists as favorites

[monken]

Because it's completely independent from metacpan.org which uses an access token and not the api.metacpan.org cookie (which wouldn't work anyway)

Sent from my iPhone

On Mar 22, 2013, at 12:34 PM, Randy Stauner notifications@github.com wrote:

While my /user is still {} it doesn't seem to keep me from marking new dists as favorites

—
Reply to this email directly or view it on GitHub.

[rwstauner]

I can also update my profile through the website... I guess I'm not understanding what the api user token is for.

[monken]

that's just OAuth. If you work on a website that uses Facebook for auth, you don't have to be logged into facebook after you authenticated once to use that page. Same with api.metacpan.org
There is also https://api.metacpan.org/login to force a login on the api side.

I guess the right thing to do is to have metacpan.org show the access_token plus the possibility to create new access_tokens for CLI use.

[ranguard]

Not seen this as an issue in a while... Closing as part of Nov 2014 cleanup