All set to output
There is no need for them to be in a repeat - just 3 regular steps at the begging of the file will do it.
Just a question - are you using the latest version of Wappler, as in previous versions there was an issues passing {{$_SESSION.name_here}} in server connect steps?
Repeat removed, latest version 1.7.2
Could you try removing the dmxConnectLib folder locally, re-save your action file (so it gets recreated), and upload it to the server again 
The IP is critical, the lat. lng is a bonus. I assume if I create a $_SERVER.REMOTE_ADDR in server action it will give the server address and not the client address as the script is called from app connect (or have i got that wrong)?
Just the record make sure you save a server action to update server connect files to the latest, as we did fix some server connect issues with $_SESSION in PHP
Yes, it will be recreated on saving the server action. Then make sure to upload it to the server.
Still not working, is there a way of detecting client IP at server connect end? I can live with IP only for the moment
That is strange as testing locally the same steps work perfectly well.
No, as it will return the server IP (as the server action runs there).
You can create a GET var for the IP and populate it on the front end using <?php echo $_SERVER[REMOTE_ADDR];?>
Hmm, client doesn’t want that info exposed in the URL hence the use of sessions
Need to think about this one
want ftp access to take a look?
Got this working via $_GET, will vist sessions another day
Thanks for all your help
Brian, you are confusing client side sessions with server side session variables!
Those are two separate worlds!
Browser/client side sessions live within the browser session and are available only client side. Managed with State Manager
Server side sessions live totally on server side only and are managed with server connect set/get session variable actions and also available only server side as $_SESSION. Available while the PHP user session is active.
So again two different worlds.
Thanks @George now i understand. I mistakenly assumed the sessions created within app connect were replicated to server sessions via the session state manager. Guess i got that one wrong big style.
$_GET alternative working OK, , client is happy so i am happy
Thanks again for your time and assistance
1 Like
Set the values as Cookies Brian. It will get the job done without exposing the data (in the URL) until you can resolve your Session issues.
yes. looking at that now, settling a cookie on login and using that as a reference. seems to only viable solution. $_GET works but is a lot of work when evey query needs to becaudited. Always preferred sessions in the past as they are destroyed at logout/ session end but it is the only viable solution I think
Starting the think it was me that’s mad using sessions, why didn’t i use cookies in the first place
set cookie on login, everything is then server connect side, no rechecking IP and geo coords on each page, doddle.
Need to give myself a serious talking to!
3 Likes
We love Cookies. Set/Remove/Expire all so simple. Used correctly they can help with all sorts of scenarios and can save a huge amount of unnecessary effort. It’s worth insuring your Users have Cookies enabled by using the Browser component to display an Alert and hide any content if the User has Cookies disabled, prompting them to enable Cookies, and preventing unnecessary reports of errors by Users with Cookies disabled. We usually apply a ‘CookieCheck’ Div enclosing the primary content area. Then this way if the Users Cookie permissions are set to disabled no content is displayed aside from the aforementioned Alert. 
Glad you have it sorted and am sure your Client will be happy with the result!
2 Likes