GitHub dependance

[Anthony-Jhoiro]

Hi ! I want to use Outstatic for more projects, but the authentication with GitHub creates significant issues when it comes to clients. I would prefer having the choice of the authentication method. A good library for that is next-auth, which I often use.

I took a look at the repository, and I understood why it was built like this. This is done so the user is already identified with the GitHub API to make the required requests. The issue is that it blocks the addition of new authentication methods. I suggest decorrelating the user from the GitHub API authentication but keeping it for the history. I can see it done like this :

• Move the GitHub API calls to the server side (this will allow more clarity on the page components in the library)
• Add the option to make GitHub requests by a default user, which would be identified through environment variables
• Add next-auth to allow more possibilities for authentication with an isAuthorized() method to check if the user can access the edition pages
• Check on the server side if the user is logged in using GitHub; if yes, use this user, or else use the default user

In my opinion, this would open a lot of possibilities for the new features and make the code a lot clearer

What do you think of this idea?

I looked at the discussion #54, but I wasn't sure if it fits. I can still change it if needed

[avitorio]

Hey @Anthony-Jhoiro, thank you so much for taking the time to bring this up. I think this is an interested concept. As I've mentioned on Discord, I'm on parental leave but should be back soon. I'm tagging one of the maintainers here so you can further discuss the possibilities of this approach. I really like next-auth.

We are adding a new feature soon which changes quite a lot of the code (#93).

But feel free to create a proof-of-concept if you'd like and tag me here once you have it. Keep in mind we use Github for the image uploads previews as well. Cheers!

[Anthony-Jhoiro]

Hello ! @avitorio ! I started a proof of concept but encountered an issue when dealing with images. Since I need to handle the commit on the server side, I had some 413 errors when I tried to communicate with the API. The solution I have so far is to increase the bodyParser Size limit of the API to 20 MB but I don't like it since it won't work with multiple images. I was wondering if it would be a bad idea to commit the images individually and then the content. If we handle it in parallel, it shouldn't increase the delay on the author side, but it will impact the Git History. What do you think about this?

I like the idea of a configuration @jakobo, I'll try to implement it soon!

The link to my branch, If you want to take a look https://github.com/Anthony-Jhoiro/outstatic/tree/poc/server-api

[avitorio]

Thank you @Anthony-Jhoiro! I'll review your work soon. 🤩

[avitorio]

Hey @Anthony-Jhoiro, just took the time to look at your repo. It is looking quite good.

The issue with the images is a bit annoying, and making multiple commits on save doesn't seem like the ideal way to do things.
How would the commits be split? Would each image result in a commit?

If doing this will allow users to log in to Outstatic using other more popular sign in options then I'd say it's an ok price to pay.
I'd like to see it in action before making a decision though.

[Anthony-Jhoiro]

Hey @avitorio !

Thanks for your answer. I was thinking about this issue and I have the beginning of an answer. Instead adding all the commits to the main branch we could add each file in a separate commit on a new branch. Then we can create a new PR and squash and merge it on our main branch. That will results in a single commit on the main branch with all changes.

I think it could be a nice compromise

[avitorio]

Interesting. Perhaps a PR is not even needed, just squash merging should be enough. Ideally we would auto-delete de branch afterwards.