🚀 Feature: Account.isLoggedIn()

[minecrawler]

🔖 Feature description

API function which allows a client to check if a user is logged in at the moment and returns the relevant information, like user type, which can be used by a client to take further steps (get account info, get session)

200 GET /.../account/sessions

{
  "user": "guest" | "anonymous" | "normal"
}

• guest means that the user has no session
• anonymous is returned when a user has a session, but it's only an anonymous session
• normal means that the user has a session and is registered (not anonymous)

🎤 Pitch

There seems to be no good way to test if a user has a session or is logged in. Using the getters for account info, sessions and current session are very spammy and verbose in the console.

As a customer of Appwrite, I'm forced to roll my own logic, which feels more like a workaround.

In order to have a proper way to check if a user is already connected in any way with appwrite, it would be great to have an endpoint which returns a status 2xx and information describing the status, e.g. guest user, anonymous user, normal user. That way, an app can either create a new session or fetch account information.

Alternative

One alternative which would work great is if the account.get() and account.session('current') API endpoints could properly communicate that no user is logged in instead of blowing up with 401 status and error logs.

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[stnguyen90]

@minecrawler thanks for creating this issue! 🙏🏼 account.get() is the suggested way to determine if a user is logged in and if they have an anonymous session or not.

• If account.get() throws an exception (with type == 'general_unauthorized_scope' and code == 401), the user is a guest.
• If account.get() returns a user without an email or phone, user is anonymous
• otherwise, the user is a regular user.

Btw, the suggested flow on app start is mentioned here: #3938 (comment)

[minecrawler]

@stnguyen90 Thank you for your reply and the link. This might be just my opinion, but I learned that this kind of usage is an anti-pattern for exceptions (in JS). To borrow someone else's words:

The use case that exceptions were designed for is "I just encountered a situation that I cannot deal with properly at this point, because I don't have enough context to handle it, but the routine that called me (or something further up the call stack) ought to know how to handle it."

The secondary use case is "I just encountered a serious error, and right now getting out of this control flow to prevent data corruption or other damage is more important than trying to continue onward."

If you're not using exceptions for one of these two reasons, there's probably a better way to do it.

So, having account.get() throw is like a punch to my face, telling me I did something wrong and there's no good way to handle it, hence I need a workaround.

Maybe that's just my opinion and the appwrite way is to use the exception throw. In that case I'll gladly follow the docs! My only wish would be to add it to the (Getting Started) docs and not only have it as a Github comment :)

[Depender-Sethi]

Hey @stnguyen90, I appreciate your detailed explanation and the link you provided. I tend to agree with @minecrawler on this one. Using exceptions for control flow can indeed be seen as an anti-pattern in JavaScript, and I resonate with the sentiment that it feels like a punch to the face when you're essentially being told you did something wrong without a clear way to handle it gracefully.

In the spirit of making the library more user-friendly, I'd like to second @minecrawler's suggestion. Having account.get() return null instead of throwing an error when the user is not logged in could provide a cleaner and more predictable way to handle such scenarios. This approach aligns with a more common JavaScript practice and might make the user experience smoother for developers working with Appwrite.

[stnguyen90]

@Depender-Sethi, please make sure to 👍🏼 the issue.