Thank you. That sounds exactly like what I need.
For today's demo I have taken the brute force approach and am running the check on every page load as to whether they are enrolled on the hidden course and if they are redirecting them to the error page linking them to finance. So I don't need to log them out because whatever they try and do, even if they have some direct link to the course they want access to it will run the check and divert them away from Moodle.
My concern with that, as above is that making a call like this:
For today's demo I have taken the brute force approach and am running the check on every page load as to whether they are enrolled on the hidden course and if they are redirecting them to the error page linking them to finance. So I don't need to log them out because whatever they try and do, even if they have some direct link to the course they want access to it will run the check and divert them away from Moodle.
My concern with that, as above is that making a call like this:
request.open("GET", "/local/obu_indicators/get.php?name=F3", false);
request.send(null);
if (request.responseText == "F3") {...will be too much of an overhead. So as soon as I've done my demo today and they are relatively happy I will apply your suggestion, checking first if the referring page was login.php and log them out before diverting them.
As I say - the longer term solution is to use a database trigger in oracle to tell us when the hold table changed in the student record system and apply the suspended flag, maybe (though thinking about that, that will simply refuse to let them in rather than divert them to another page to explain it).