How to determine current user on a page?

We’re experimenting with Backendless for our web app’s, well, backend. I’m successfully pulling lists of data and the like for general test users and have a login/register function established. But how exactly do we set the login to be persistent and to display data on the user’s own profile page specific to them?

The long story:
As I’ve described in previous threads, our app uses profile pages as the primary engagement mechanism. We’ve determined that at least two such pages are necessary, titled “pUserProfile” and “sUserProfile”. The ‘P’ and ‘U’ prefixes stand for Primary (the logged in user’s profile) and Secondary (the profile pages of other users that the primary user may view).

With that said, our login/register pages have logic set up to carry the user over to their pUserProfile page. The question is how to set the page to draw data specific to that single user and no one else? I’m going to guess we don’t yet have true authentication set up on a per-page basis as I have to enable “Allow page to be opened without authentication” in order to actually load the pUserProfile page. If someone could give us a starting point on this part, we’d be much obliged!

Addendum: Backendless has limited information on getting the current user, but without the ability to plug in JavaScript, I’ll need an alternative. Get Current User - Backendless SDK for JavaScript API Documentation

If you can setup (simple HTML/JS app separate from AppGyver) the use of the Backendless javascript call then you could use the Chrome browser Inspect capability to see what API is being called when you invoke their JS user call (per your link).

It is a bit of work but it could get you the API they use under the hood with their javascript library.

Great idea pulling the API via Inspect! Thanks for the suggestion. I’ll look into tonight. But I was more curious as to where it all connects with Appgyver. For example, we’ve connected the API to register and login the user (and it does work). So now, we’d need to have that “connection” be, in essence, permanent for the duration of time the user is logged in. I meant this purely in relation to Appgyver.

It makes sense that we’d connect/built a third REST API to represent the current user so that all actions they’d take affect only their account data on Backendless. So it would be connecting that API key for currentUser, binding it to page/data variables on pages built for signed-in users, and then streaming that data.

But I’m uncertain if that would be enough to be considered authentication by Appgyver to make disabling the aforementioned “Allow page to be opened without authentication” checkbox actually work
– thus, meaning only a signed-in user can access the page. We’ll dabble around with it some more soon, but if you or someone else could provide some deeper insight, that’d be great!

Thank you,
Dom

With AppGyver, once you call dismiss initial view the remainder of your app is loaded. That would be all of the screens that need to have authentication (dismiss initial view).

I hadn’t really thought about it in the terms you’re talking about, but once you call dismiss initial view I am assuming that AppGyver considers the user authenticated and logged in. At that point they can navigate to any of the screens in the app.

And of course if your call to backendless to login the user is not successful, then you don’t call dismiss initial view and they can’t get to any of the other screens because the app isn’t loaded. They just remain on your login screen.

For me, once I call in to my backend server (Nocode Xano server), I store the auth token to local storage and then call dismiss initial view and at that point the user can get to any of the screens that need authentication to be displayed.

I don’t know if this helps what you were looking for :grinning: when I read back over it it seems a little long winded of me

1 Like

Ah, you see, I didn’t know about the dismiss initial view logic component before you mentioned it. Originally, we had a Load Page load component leading to the signed-in user’s profile. There lied the issue of how to bring in data specific to said user.

Now that you mention it, we’ll see about adjusting the order of our pages to fit that schema and, hopefully, that’ll take us somewhere. I’m not yet sure if setting that up and then connecting it to an API is all that’s necessary, but we’ll see.

Thank you, Steve!

1 Like

And regarding auth tokens, if you don’t mind sharing, how would you store them to local storage, in your experience? Mind you, this is a responsive web app that can be used in browsers on any device. I’ve been ripping apart the docs but all I see are articles for Appgyver’s own auth system. Do you store the tokens as app variables?

And before I forget, we do have at least three pages (Welcome to [Appname], Login, and Register) which should not have authentication required. I tried setting the navigation list to have those three at the top with the first “authentication required” page, the profile, immediately under them with the assumption that it would bypass any of the other no-auth pages once signed in/up and jump immediately to the profile.

It didn’t quite work out, possibly, because authentication still isn’t set up correctly with tokens. So I deleted all but the Welcome page in the list right now. In the image below, Welcome is the only page without auth required.

Thank you for lending your time. I think, once we figure this out, the rest should line up neatly.

Yes, no go there. Anyone have an insight?

Thank you.

I have a couple of videos on my youtube channel that might help you. They walk you through how to do Authentication with AppGyver and Xano. Eventhough you don’t use Xano, the AppGyver side of it will be helpful. It shows you how to do a signup and login and save the authtoken to local storage and do the checks to do auto-login.

Let me know if that helps you solve your login/authtoken questions.

2 Likes

Quite literally, five minutes ago, we had figured it out and I was about to write as much here. Turns out, the official tutorial for Appgyver/Backendless integration didn’t quite cover the whole story there on storing tokens, etc. But we do greatly appreciate your insight, Steve! Thank you for your time. :slight_smile:

For anyone else stumbling upon this in regards to Backendless, here are the two tutorials we used to figure this out. The first is Backendless’ own, but it does, as of this writing, seem to be missing some key functions as I mentioned before. The second tutorial set actually covers storing auth tokens and the like. So now, we have successfully been able to sign into our app and steam data from our backend!

https://symmetricdynamite.gitbook.io/backendless-appgyver/

4 Likes

That is great news! Thanks for sharing. I’m sure we’ll run into each other as we both continue building.

2 Likes

Hey, Steve. Thanks, mate! We just might.

Any chance you have a tutorial with Xano on determining other users that you could point out? While we are currently using Backendless and have user authentication set up, it’s still a bit tricky wrapping our minds around the tokens for streaming other user data. So for example, where the signed-in user could go to their Friends list, click any name in the list and see the profile page for them – and then, go back to the Friends list, click another name, and go to the same “page” but, of course, this time streaming in the next user’s information.

I’d guess the general setup in Appgyver is the same regardless of backend. Some insight would be awesome!

Hey @Dominik_Greene! If you start with the video #4 in my AppGyver & Xano playlist I think you will get the exact answer you need.

The approach for me video is having a list of todos and tapping a specific todo and having it open in a screen that shows its details. Obviously, you are using a Friend list instead of a list of todos, but the approach will be the same.

Let me know if this gets you going!

1 Like

Thank for this! I’ll give it a look during my work break and see if it applies this coming weekend. Really appreciate your assistance, mate!

1 Like