0

I'm currently refactoring some legacy code which didn't contain much AJAX. Lots of stuff is already finished, but there is one thing I'm currently a bit clueless what to do with it. It's the following function:

function CheckForLogin(){
  var loginStatus = <?php if(ISSET($_SESSION["loggedUser"])){
    echo 1;
  }else{
    echo 0;
  }?>;

  if(loginStatus == 1){
    //console.log("CheckForLogin returned ", true)
    return true;
  }else{
    //console.log("CheckForLogin returned ", false)
    return false;
  }
}

It's used in many places, controlling the flow of the program depending on the loginstatus of the user, like this for example:

if(checkForLogin()){
//doStuff
}else{
//do some other stuff
}

Now, if I make this code asynchronous, how can I make the result of the AJAX call visible to the if? Because once I enter the asynchronous world, the results from there can't really be returned back into the synchronous world (unless I'm using globals or just write the results into some element, database etc.), as far as I understood.

In other words, I'm afraid that all I can return from "checkForLogin()" is a promise object, once I made the server interaction an AJAX.

So, my first question is: Do you think it is a viable solution to just leave the "intermingling" of JS and php as it is right now? Or do you think that the benefits of making this asynchronous and separate php from JS will outweigh the downsides?

And my second question is: If you would advise making this very frequent Check Asynchronous, how can I do it without making the code a hellhole?^^ Using promises inside the normal flow of functions is actually pretty nice, especially compared to using callbacks. But using them inside if-statements? Or is there some way to return the true/false directly depending on the result of the AJAX?

ForeFather321
  • 179
  • 2
  • 9
  • if you want to transform a sync code to an async code then you need to modify each file where this function is being called, so, be careful. In the other hand, any system should just perform the operations to the backend and backend will return the proper 401 is the access is not authorise. What frontend can do is store ttl for access token in order to know when a session is not valid for sure. – Jose Mato Aug 29 '18 at 14:16
  • Your question is really broad, opinion based, and contains many topics. As of that it is not really answer able, at least not in a meaningful way. If you are able to use `await`/`async` then the asynchronous code would not really look much different to its synchronous counterpart: `if( await checkForLogin()) { } else {}`. For a web app the general aim is to have a good separation between data handling and ui, so that you are able to do easier updates and migrations. – t.niese Aug 29 '18 at 14:20
  • Ignoring the main jist of this question, Both your existing and new proposals for checking whether someone is logged in are totally insecure and easily bypassed. All your security code should exist server side only. – Liam Aug 29 '18 at 14:27
  • @t.niese okay, if I use "if( await checkForLogin())", how does the "if" still "see" the actual returnvalue, which would be "true" or "false" in this case? After all, "checkForLogin()" would return a promise, so how can the "if" clause still see either true or false? – ForeFather321 Aug 30 '18 at 06:17
  • @ForeFather321 Well that's the whole purpose of `await`/`async` it was introduced to work with Promises in a way that is as close sync code as possible. `await` interrupts the code execution at that point and continues at that point as soon as the promise `checkForLogin()` is not pending anymore. If the Promise is resolve the await _"converts"_ the promise to its resolved value, it was rejected an exceptions is thrown, that can be cached by a try catch block. [see this fiddle](https://jsfiddle.net/gosrk0cz/5/) – t.niese Aug 30 '18 at 07:30
  • @t.niese wow, thats cool! about your new promise parameter/constructor. So far I learned that the promise takes exactly one parameter, the function im passing to. The two things in the "new promise" constructor/parameter (?) are ALWAYS resolve/reject. No matter how I name them. Maybe I didn't understand this correctly, however: Does it matter in any way that you wrote "new promise (_, reject)" and "new promise(resolve,_)" other than for illustration (since the respective functions either only rejected or only resolved)? – ForeFather321 Aug 30 '18 at 08:36
  • 1
    Do not ask new questions in the comment section. The comment section is for clarification of question related to the original question. (Yes the [Promise constructor](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) has one parameter, the promise callback has two parameters `resolve`/`reject` that can be named whatever you like, but it is recommended to use `resolve`/`reject`, [Underscore as a JavaScript variable?](https://stackoverflow.com/questions/11406823/underscore-as-a-javascript-variable)). – t.niese Aug 30 '18 at 10:03
  • It's more normal, safer and simpler for client-side code never to see a `loginStatus` var. Instead, allow login status to be the concern of the server-side code when requested by the client to do something. As far as the client is concerned, each ajax (or regular http) request either succeeds or fails; one of the reasons for failure being that the server determined the user was not logged in. It is also good practice for the server to invite the user to log in when a request fails for reason of not being logged in. The whole thing requires a different mindset from where you are at the moment. – Roamer-1888 Sep 01 '18 at 12:00

0 Answers0