Bypass logging in if viewing public repos only

[nknguyenhc]

Is your feature request related to a problem? Please describe.

The user has to login to WATcher regardless of whether they are viewing public repos only or including private repos. If the user is viewing public repos only, it does not make sense to require them to log in.

Furthermore, viewing any repo (by pasting the link directly to the browser) requires logging in regardless of whether the repo is public or private.

Describe the solution you'd like

Skip the login if the user only views public repo.

If the user visits the link to directly view a repo, the user should be able to view the repo without being redirected to the login page, if the repo is public.

Describe alternatives you've considered
NIL

Additional context
NIL

[damithc]

Good suggestion. Perhaps prompt for login only if the user requests to view a private repo, or perform some action that requires authentication (e.g., a write operation)

[gycgabriel]

I'm under the impression we need the github login to call github API

https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-primary-rate-limits

Would be good to prompt login if we exceed the rate without github login

[damithc]

I'm under the impression we need the github login to call github API

https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-primary-rate-limits

Would be good to prompt login if we exceed the rate without github login

Good point @gycgabriel

[nknguyenhc]

@gycgabriel @damithc I have attempted to bypass logging in when viewing a public repo, but unable to fetch issues from GraphQL API endpoint.

It looks like Github does not allow access to GraphQL API from users not logged in. From Github GraphQL docs, it does look like one has to authenticate before using the GraphQL API endpoints. For reference, a REST endpoint not requiring Github login (with rate limit 60/hr) looks something like this:

I am thinking of the following possible solutions, but I am not sure how feasible they are:

1. Switch away from GraphQL endpoints to REST.
2. Persist logging in credentials, so that when user visits a link to view a repo, does not have to log in again.

I would love to hear what you would suggest, or if I have missed out anything important!

[damithc]

When the user login, what level of access is requested from the user? If it is read access to public repos, it might be more acceptable than asking for write access to private repos.

[nknguyenhc]

When the user login, what level of access is requested from the user? If it is read access to public repos, it might be more acceptable than asking for write access to private repos.

Currently, logging in to view public repos requests for read & write access to user's public repos (scope name public_repo), and logging in to view private repos requests for read & write access to user's all repos (scope name repo). Reference: Github scopes for OAuth apps.

With bypass logging in, the app does not ask for any read or write access from user. That is, the user is browsing the app as a public, not logged in, user.

[damithc]

I'm not sure if switching between REST and GQL is worth the benefit of 60 API calls.
Persisting logging info does not solve the problem of the user needing to login the first time she uses WATcher (because it's the first impression that we are trying to improve).
Perhaps we leave it as is for now?

[nknguyenhc]

@damithc In that case, to improve user experience for first time user, I think what we can do is to simplify the login process? I can imagine the use case as follows:

1. User paste the WATcher URL to view a repo into the browser.
2. Our app redirect to Github for authentication.
3. User authenticates on Github.
4. Github redirect to the correct page to view the repo.

As of now, the process is rather complicated because our URL does not indicate the repo one is viewing, and our app does not redirect to the intended landing page upon logging in, so the process is currently as follows:

1. User logs in WATcher and clicks login.
2. Our app redirect to Github for authentication.
3. User authenticates on Github.
4. Github redirects to our page.
5. User confirms logging in.
6. User indicates the repository to view.
7. Our app redirects to the page to view the repository.

This enhancement still requires the user to login to Github, but I believe it should simplify the process and improve user experience?

[damithc]

I can imagine the use case as follows:

1. User paste the WATcher URL to view a repo into the browser.
2. Our app redirect to Github for authentication.
3. User authenticates on Github.
4. Github redirect to the correct page to view the repo.

@nknguyenhc You are right, that should be the workflow. But it is not strictly about bypassing the login, so best posted as a separate issue.