Maybe I've missed a step on this one but here goes.
I have a Drupal installation that ultimately contains a Flash application. That Flash application needs to interface, to a small degree, with Drupal. So, instead of reinventing the wheel, I thought I'd piggyback off of Flash Remoting and XMLRPC. (This may be my fundamental flaw here.)
The Flash application uses Remoting to communicate with a PHP class containing a number of methods. One of those methods queries the Drupal XMLRPC interface to get the current $user->uid;. The communication between these elements is fine. The problem is the result for $user->uid;
Defining global $user; and returning $user->uid; yields nothing.
function amfconduit_getUID() {
global $user;
// return the complete $user object
return new xmlrpcresp(new xmlrpcval($user, 'struct'));
}
To debug I slimmed down the returned value to just the $user struct. The returned value is good except that all of the VALUES in the KEY, VALUE pairs are null/empty.
This befuddles me. I've run some tests with other global variables, defined at the tail of includes/bootstrap.inc and they all return fine. Why doesn't $user?
Comments
A quick guess ...
You know, perhaps the PHPSESSID is not used when you do the Flash (amfphp?) remoting call ? Just a guess ...
You could get it off the cookie, and use it in the requesting URL.
Sounds like a good place to start.
I'll take a look. Do you have any thoughts on how I might get the PHPSESSID value from the cookie?
I've Done More Testing
And can safely say that session.inc is being called upon my query.
I ran this test within sess_read($key).
Then in my xmlrpc/module procedure I returned $foo.
$foo returned a completely different Key than what my _COOKIE was storing. So, it's pretty safe to say that my module procedure is a little confused. Which, needless to say, confuses me.
As another test, I tried accessing $base_url. That worked. Funny.
Still need help.
Still seems to be it ..
To me it sounds like there are two different connections, with two different session-ids. One is authenticated as a user, the other is anonymous. Still going by a hunch here, but your description just seems to still indicate that's the case.
Try doing a dump/log of the HTTP headers to be sure.
For doing the cookie interaction, check out this:
http://www.permadi.com/tutorial/flashCookie/
or just google for flash cookie or fscommand getcookie setcookie .
return new xmlrpcresp(new xmlrpcval($user, 'struct')) ????
return $user;in 4.6.3 and beyond.--
Read my developer blog on Drupal4hu.
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
two sessions ?
... but don't you think it sounds like two sessions are being created - one authenticated via the browser main window URL and the other via a Flash swf connection ?
If he tried some javascript AJAX XMLHttpRequest-style connection maybe he would be able to use the same cookie, but would end up borking a lot with try-catch browser compatibility and more.
Give the two different session ids he is seeing it would seem the logical lead, no ?
... but don't you think it
This is where the confusion is. The XMLRPC call doesn't originate from Flash, it originates from a services file that Flash queries via amfphp.
Flash remotes to Services.php. Services.php uses the XMLRPC libraries to query Drupal's XMLRPC interface. Drupal returns values to Services.php which in turn returns them to Flash.
Services.php resides on the same server as the Drupal install... actually, it's inside the 'includes' directory, two directories deeper than bootstrap.inc.
Can one of you tell me...
How one gets the communication between services.php and the xmlrpc library to work? I am having trouble with this, and I posted this forum topic regarding my confusion.
Thanks,
-- aym
Not sure...
I'm not sure you can do that with XMLRPC. XMLRPC clients expect a properly formatted xmlrpcresp.
and they shall have it
When you return something from hook_xmlrpc , the XMLRPC library will take of XML-RPC encoding it.
--
Read my developer blog on Drupal4hu.
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
Newer version of XMLRPC library
What chx was saying is that there is a newer version of the xmlrpc library that completely changes the syntax of all xmlrpc work (and makes it much easier). You should definitely upgrade to 4.6.3 or HEAD before proceeding with your work.
I did Flash XML-RPC integration once and my solution at the time was to output something to identify the session in the flashvars that load the Flash. Flash then sent that hash back with the xmlrpc request and the current user was loaded from that. The other way would be to use javascript to get the cookie and send the cookie or session id with the Flash XMLRPC request.
In any case, the problem has been correctly identified; the flash request isn't sharing the session with the browser request.
Your choice of technologies, by the way, is very good and powerful, and when you have success, please do a writeup of your experience. A flash client can access the entire Drupal API via XMLRPC and this opens up lots of possibilites.
Check out the flash objects on the front page of webs4.com - they use XML-RPC to interact with NowPublic.com.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net