master can't push a message to a client

[Google Code Exporter]

What steps will reproduce the problem?
1. in one browser, let's say IE, create a zombie, extend with an onpull
function and start it. (victim)
2. in another browser, say FF, create another zombie, list victim zombies,
and send a message via push("alert(1)", "GLOBAL") 

What is the expected output? What do you see instead?
I should see the "alert(1)" message at the victim's onpull function.

What version of the product are you using? On what operating system?
2.2.0a, XPSP2

Please provide any additional information below.

should I have sent an email instead I don't know. Anyways here it goes;

In AttackAPI 2.2.0a, in "AttackAPI.dom.spawnChannel" method, there are
"transport" and "evaluate" functions. These functions send "referrer" query
parameters. 

With these in hand, a master (yet another zombie, in fact) can't push
messages to clients, since clients fetch their corresponding messages
indexed via their referrers:

array_shift($_SESSION['_message_queue'][$REFERRER])

Actually I didn't try hard to understand but what do you use referrers for?

My patch was to do this;

function transport(query) {
  AttackAPI.core.extend(query, {
    /*referrer: channel.referrer,*/
    __r: Math.random() + '_' + new Date().getTime()});
    AttackAPI.dom.transport({url: channel.location, query: query});
}

same with the evaluate function...

Original issue reported on code.google.com by [e-mail] on 2 May 2007 at 12:35

[Google Code Exporter]

By the way, it seems to be $_SERVER['HTTP_REFERER'] with a single R. :) And all 
this 
time I was thinking why in the world channel.php bypasses 

 isset($_SERVER['HTTP_REFERRER'] 

expression and assigns $REFERRER global parameter the value of _

All and all, as I've stated earlier, I like attackAPI and your blog very much. 

P.S: I checked svn for attackAPI 3 branch, and felt some heavy weight 
structural 
changes. hmmm... 

Original comment by [e-mail] on 2 May 2007 at 5:45

[Google Code Exporter]

thanks,

AttackAPI3 branch is in sort of experimental stage at the moment. I will give 
it a
serious thought before I go and do something crazy with it, like restructuring 
the
entire project.

Thanks for the bug submits... I will fix the as soon as possible.

Keep the good work.

P.S: Do you have any ideas on how to make the library more usable and easier to
maintain and extend?

Original comment by pdp.gnucitizen on 3 May 2007 at 8:24

[Google Code Exporter]

I can't really suggest a more clever way of restructuring the api, however,
I think anyone who has some knowledge of closures, "this" scope and simple oop 
understanding in javascript would understand attackAPI's code, thus will be 
able 
extend it. (same with the maintainance, I guess)

But one thing I know, as an end user, is that it would be really nice if we had 
some 
kind of API documentation and equally importantly logic documentation (by this 
I 
mean the internal logic of how individual attack vectors work and implemented, 
a 
nice graphical representation of channels, maybe). That is to say, usability is 
good 
and can be better with a nice documentation. At 3 branch I can see you are 
doing 
this in code.

I can't say I don't have time to pull this out and help you (and everyone 
interested, thereof) out. I don't know. Maybe I should...

your thoughts???

Original comment by [e-mail] on 6 May 2007 at 7:24

[Google Code Exporter]

Original comment by pdp.gnucitizen on 10 Feb 2011 at 4:51

• Changed state: WontFix