sc_redir not working from Cron

Scriptcase 9 General
#1

So as the subject says, I have noticed that if I have a blank app that redirects to another blank app using sc_redir that if I call that app from a cron job using wget on a Linux Apache system that the redirect does not work.

Basically I have several “processes” that do various things in Scriptcase Blank apps… these apps take session or get/post variables and do something with them, then pass the user on to the next app in the sequence using a variable given from the previous app.

This way I can have these processes be called from any application… this works flawlessly from the browser, but does NOT work when I try it from a cron job using WGET.

anyone have any suggestions for ways to pass data around from app to app from a cron job?
Thanks!

#2

That is an interesting concept. Not sure I 100% understand it, but let’s see if I can. How would a cron get session variables? A cron is not a logged in user so how can it know whose session variables to grab?

#3

The CRON calls the first app in the sequence… that app may set a session variable that needs to get passed to the next app.
My Real World Example:

Cron calls App “Queue processor”
Queue processor checks for records in “queue” table in database.
When record is found it takes that record number and looks up data required to “process” the item.
Queue Processor redirects to App “Process item” passing it the item # from queue table.
Process Item app may need to call various other apps to complete processing of item… each app takes a session or GET variable from URL to know what item to do its job on.

I have this working using CURL now… but it won’t work with SC_REDIR macro. Using CURL I pass the variable on the URL… which limits me perhaps a little… would be nice if I could pass POST variables or session variables using SC_REDIR.

 // create a new cURL resource
$ch = curl_init();

// set URL and other appropriate options
curl_setopt($ch, CURLOPT_URL, "http://192.168.0.127:8090/scriptcase/app/MyProject/RedirectTest2/RedirectTest2.php?data=From%20Curl1&data2=From%20Curl%20also");
curl_setopt($ch, CURLOPT_HEADER, false);

// grab URL and pass it to the browser
curl_exec($ch);

// close cURL resource, and free up system resources
curl_close($ch);

App called "RedirectTest1.php writes one record to a table in the DB, then passes to app RedirectTest2.php the variables “data” and “data2”… app RedirectTest2.php write those variable to the database.
This way I can see it working.

As I said the only downside to this is requiring me to use GET variables via URL… I would like to use session [VARIABLES] perhaps… but don’t know if that would be possible.

Thanks!

#4

Just an update… session variable DO NOT work using CURL (Figured they wouldnt) but this works effectively for GET type variables in the URL and I have read those are only limited to 2048 and SOMETIME 1024 Kb in older browsers… so Im using the CURL method above with great success.

#5

I am not sure that session variables would work with a cron unless it mimics the login procedure. Session variables are particular to the user who is logged in, so your Curl, or any other mechanism would need replicate a logged in user. This is not an SC issue in my opinion but more a coding issue in general. I do however use cron successfully too. For those who may stumble across this post, the trick is to ensure that the security section of a blank applications is set to no security. A session variable is a kind of cookie, and it is not normal to use cookies with a cron. I would not do it that way, but then again, that is just me!

#6

I have another follow up on this, something very interesting that caused hours of frustration on my part.
These are all “blank” applications in Scriptcase.

App1 is called from Cron Job.
App1 uses Curl to call App2 with URL variables.
App2 uses Curl to call App3 with URL variables. <-- Fails in Scriptcase Apache server instance.

The same process works perfectly in my production environment… so that is to say that I can only call one app level deep via curl from within the “Scriptcase Apache” instance, but the production server I have and consequently once deployed to my dev server, NOT running under port 8090 for Scriptcase, then this works

I hope that is useful for someone one day :slight_smile: