Utilize integrated account as a card back

[Oatelaus]

As SHIO allows both GitHub and Discord profile pictures, I think it would be beneficial to pick up these as card backs for when someone logs in using one of these methods. I think it should be automatic without 50 required games to play as Discord and Github both police their image uploads and the terms of service will probably match the requirements of SHIO's image uploads.

It will not require either bandwidth nor storage space (on the SHIO servers) for these images as they will be hosted via the third party CDN but still allow users to upload a custom card once they have hit the required amount of games.

I think for the sake of it, it should also allow you to use the default card back if you don't want to use the integrated accounts associated image.

One issue I can see currently is that the card back images are not a common profile picture size, but uploading my current profile picture from here came out okay, so I think this would depend on the image shown.

[cozuya]

Cool idea not sure how it would be implemented though. Will think about it.

[Oatelaus]

@cozuya

GitHub will allow you to retrieve the users profile picture via similar to the following:

https://github.com/Fedelaus.png https://github.com/cozuya.png

you appear to track GitHub username here:

https://github.com/cozuya/secret-hitler/blob/0c6fa4bd115af2c5c9dbe8fcb4a085edcf25d766/routes/accounts.js#L252

You appear to be retrieving a user object from Discord here

https://github.com/cozuya/secret-hitler/blob/0c6fa4bd115af2c5c9dbe8fcb4a085edcf25d766/routes/accounts.js#L250

This object would have an avatar hash within it.

I'm unsure what the mechanism in place currently is, it feels like the easiest implementation would be to download the image and save it locally within custom-cardbacks.

A "better" solution to leverage the third party CDNs could be to wrap the route custom-cardbacks as an express route and default to the file system if the user doesn't have an avatar set within the database and 302 redirect to the third party if it does exist.

I am happy to pick this up as I believe it's low-hanging fruit but guidance on what solution you're comfortable with would be helpful (assuming this is something you want)

[iounpaladin]

May I have this assigned to me? I will likely have time in the upcoming week to set up the latter solution mentioned (wrapping custom-cardbacks).

[iounpaladin]

One thing to note is it isn't particularly easy to integrate this with Discord (on pre-existing accounts) because the relevant data (avatar URL) isn't stored. As part of this PR I can write a script to go through existing accounts with Discord integration and query avatar information, but I think that's outside the scope of this PR (therefore, I will start with just using GitHub avatar integration).

[Vigasaurus]

I think the scope of the PR for this should be to simply query GitHub/Discord profile image URLs on signup/in, save them to the account object, and add support for showing the OAuth cardback if a local one doesn't exist, as well as a way to clear the OAuth cardback permanently.

Dealing with pre-existing users should happen automatically as on sign-in the OAuth image url should get fetched (and only be used if the user doesn't have an existing local cardback or have the OAuth cardback cleared).

It may also have to look into scaling/stretching for improperly sized images.
This is a very involved issue/PR in my eyes, to be clear.

[iounpaladin]

Alright, I see what you mean. I'll start on it later today.

[iounpaladin]

Alright, here's my plan for this PR.

1. Add a new variable to account.js, called oauthCardbackUrl
2. Rewrite all requests to /custom-cardbacks/ to use cardbackUrl [ONLY if the cardback image 404s]
3. When using oauth to login/signup with an empty oauthCardbackUrl, oauthCardbackUrl is initialized to the oauth picture
4. The user can clear the avatar [setting oauthCardbackUrl to a direct link to the default avatar], or upload a new one [which will prevent oauthCardbackUrl from being used]

This PR will never affect any user with a set cardback.

[Vigasaurus]

Couldn't it instead just read cardbackURL as the field, and that even custom cardbacks would leverage this field - only with a link to the local asset. As such, a clear would remove both, and an override would easily prevent OAuth from resetting it.

[iounpaladin]

Yes, it certainly can. I was looking in the account object for a cardbackUrl before I realized it was called customCardback.