Show/Hide login/logout button when user login and logout

Merry Christmas;

I am trying to hide the logout button when user log out and show the account button. Or/And show the account button when user are not login. The account button send user to registration and login page they don’t have to go there then they are already log in. I was thinking they don’t have to see it the link that is first one, then avoid them going to registration and login page when they manually try to access the page typing the url.

Any gifted advice will be very Santa of you; Thank you

Hi @mamdi122003

Please check the documentation section, it’s explained how to create a logout button on your page:


As for the condition value - select the identity binding returned from your user details action. Click your button, select dynamic attributes - show: and bind identity binding.
If it has a value, the button will be displayed.

2 Likes

Hello Teodor,
I did the log out button already using George tutorial. It is working fine. Thanks. My issue was the fact that the log out button is still on my sight when i log out. The logout button is part of the php include I created. So, when users are not login they still see log out on top of other pages.
If I do understand the identity binding in the dynamic attributes - I can still use it on My Account link to hide it if it has value but show log out button.
However, It will check on the show attribute within an hour and let you know.

Thank you in advance

Thank you! The dynamic attribute did make the work I was looking for.

1 Like

I’m having the same problem. And I am trying to decode your instruction. I create a userDetails server action as shown in the tutorial.

This action fetch user record given the siteSecurity.identity binding.

When user is logged out, this query shows errors in the console, saying the current user is not authorized to perform server action. How can I fix it so that it simply return false?

I think a better way to do this is to access $_SESSION global variable on the server side or session storage on the front-end to stored value. This way you can refer to the session storage anytime for styling. But I cannot figure out how to check whether siteSecurity.identity is present on the front-end side. Any idea?

I got the same problem: The 401 Unauthorized error in the console when the user is not logged in. Is that a problem or can that just be ignored @Teodor? Because apart from that it all works fine…

Hopefully this will clarify things. I have a Server Connect file which contains the record of the logged in user. It has the security enforcer, then a Query Single where the condition is the identity of the logged in user. The page then has an App Connect action pointing to the Server Connect file. This means it will have either a record (if logged in) or an empty query (not logged in) so my ‘Log Out’ button simply has a ‘Show’ action where the criteria is the ID of the logged in user. This mean it shows if there’s a record and doesn’t if there isn’t.

Thanks for this post @sitestreet. My setup was likewise I think, but I tried yours as well, please see below.

This is my server action which is run on page load (“No auto load” is turned off):

And this is my “Show” dynamic attribute for the logout button:

This works, the logout button is shown only when a customer is logged in. However, when there’s no customer logged in the browser console returns a 401 Unauthorized on the server action:

Hence my question:

Found a solution in removing the Security Restrict from the Server Action:

That doesn’t make this server action unsecure, does it?

Well there are no issues in having status 401 … this mean the user is not logged in.

Do not remove the restrict step from your server action, as anyone running it in their browser will see the data returned.

1 Like

Okay thanks @Teodor. Good to know 401 status is no problem and can be ignored when user is not logged in. I thought it might be a problem because the wappler design view shows the 401 error all the time in the bottom if no user is logged in. I also thought the restrict step wasn’t necessary because the database query won’t return anything if the user is not logged in and only the user id if logged in.