google-code-backups / sabreamf

Automatically exported from code.google.com/p/sabreamf
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Deserialization issue & apparent coding error in Message.php #5

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Hi,

The deserialize() function in Message.php needs some tweaking to work with
SWX service explorer.

http://swxformat.org/php/explorer/

This is how I made it work, line 155. There may be a better way to fix it
but I hope it will help you understand the bug.

if (is_object($body['data']) && $body['data'] instanceof
SabreAMF_AMF3_Wrapper) {

                    $body['data'] = $body['data']->getData();
                    if (is_array($body['data']) && isset($body['data'][0]) &&
is_object($body['data'][0]) && $body['data'][0] instanceof
SabreAMF_AMF3_AbstractMessage) {
                        $body['data'] = $body['data'][0];
                    }

                     $this->encoding = SabreAMF_Const::AMF3;
                } else if (is_array($body['data']) &&
isset($body['data'][0]) && is_object($body['data'][0]) && $body['data'][0]
instanceof SabreAMF_AMF3_Wrapper) {
                     $body['data'] = $body['data'][0]->getData();
                     $this->encoding = SabreAMF_Const::AMF3;
                }

(Previous test was "is_object($body['data']) instanceof
SabreAMF_AMF3_Wrapper" so I think there is a mistake somewhere)

Thanks!

Original issue reported on code.google.com by sylvinus on 16 Mar 2008 at 4:32

GoogleCodeExporter commented 8 years ago
actually, my patch only fixes the call of the method. The result doesn't seem 
to be
well parsed by the service explorer, maybe because of wrapping issues ?

Thanks for your help :)

Original comment by sylvinus on 16 Mar 2008 at 4:59

GoogleCodeExporter commented 8 years ago
Hi Sylvinus,

Can you provide a dump of the request and response? Either just a binary dump 
of the
request, or better yet, one created with charles:

http://www.xk72.com/charles/

Original comment by evert...@gmail.com on 24 Mar 2008 at 2:58

GoogleCodeExporter commented 8 years ago
Hellow, I am someone else who run into the same problem. I wasn't able to use 
Charles
because apparently even Charles burfs on trying to parse this Amf request and 
just
shows nothing for the request (not tabs no nothing). Although I am very happy 
you
pointed my attention to this great tool, thanks!

Anyway, I have a attached an old-fashioned dumped which was created using
apache_request_headers and file_get_contents('php://input'). I hope it helps.

One thing which is interesting, SabreAMF seems to work fine with the actual 
requests,
it's the service browsers that seem to throw it off.

Original comment by amirab...@googlemail.com on 24 Mar 2008 at 2:06

Attachments:

GoogleCodeExporter commented 8 years ago
That is interesting, and would suggest the problems is not in the request, but 
in the
response.. I'll check out this message and see what I can do..

A charles dump would still be great, even though it won't display you the 
tabs.. It
will still have the raw data (which is what I actually need..)

But I'll first have a look without that 

Original comment by evert...@gmail.com on 24 Mar 2008 at 2:09

GoogleCodeExporter commented 8 years ago
In that case here's Charles:

Original comment by amirab...@googlemail.com on 24 Mar 2008 at 2:14

Attachments:

GoogleCodeExporter commented 8 years ago
BTW it seems like the problem is with SabreAMF_AMF3_Wrapper. It is being 
deserialized
and serialized correctly, but it seems that your SabreAMF_CallbackServer simply
forgot to handle it. In fact trying to use the example script under
examlpes/AMF3Client.php causes a similar error.

Original comment by amirab...@googlemail.com on 24 Mar 2008 at 2:25

GoogleCodeExporter commented 8 years ago
great thats good info.. there is some weird stuff going on there.. I'm 
wondering if
the servicebrowser has some special handling or doesn't use the standard 
remoting
components; but i'll check that out..

Original comment by evert...@gmail.com on 24 Mar 2008 at 3:31

GoogleCodeExporter commented 8 years ago
I have a feeling that may be that case. Note that the AmfPHP service browser 
pass a
header named "serviceBrowser" with the value TRUE.

Original comment by amirab...@googlemail.com on 24 Mar 2008 at 4:09

GoogleCodeExporter commented 8 years ago

Original comment by evert...@gmail.com on 24 Mar 2008 at 7:56

GoogleCodeExporter commented 8 years ago
Hi amirabiri,

The 'amfmessage' file decodes just fine, just like you said.. 

I can't actually open the charles file though.. I'm running the latest 3.1.4, 
what
version did you create it with? Also, it might help to zip it beforehand, maybe
uploading it mangles it somehow (but I doubt that..)

Original comment by evert...@gmail.com on 24 Mar 2008 at 8:08

GoogleCodeExporter commented 8 years ago
Also, any idea where I can fetch a copy of the swx servicebrowser source? 

Original comment by evert...@gmail.com on 24 Mar 2008 at 8:12

GoogleCodeExporter commented 8 years ago
I just downloaded the latest version of Charles, which is 3.2, today because you
mentioned it... :-) anyway if you want me to create a dump with 3.1.x just let 
me know.

I have attached a rared version.

Don't know about SWX I'm affraid.

Original comment by amirab...@googlemail.com on 24 Mar 2008 at 8:50

Attachments:

GoogleCodeExporter commented 8 years ago
Sorry bout that.. charles didn't automatically update.. I'm downloading the 
latest
version myself now too :)

Original comment by evert...@gmail.com on 24 Mar 2008 at 9:06

GoogleCodeExporter commented 8 years ago
Hi,

The dump works, thanks a lot.. Investigating this issue has lead me to some 
weird
string referencing issues in AMF3.. 

I'll hopefully have a better reply soonish 

Evert

Original comment by evert...@gmail.com on 24 Mar 2008 at 10:15

GoogleCodeExporter commented 8 years ago
What I'm not sure of, is if this will fix your problem..

do hope so though

Original comment by evert...@gmail.com on 24 Mar 2008 at 10:20

GoogleCodeExporter commented 8 years ago
Can you attach the fix?

BTW I'm using 1.0.174. I hope you intend to incorporate the fix to 1.0.

Original comment by amirab...@googlemail.com on 24 Mar 2008 at 11:22

GoogleCodeExporter commented 8 years ago
Try the current SVN version, this will fix an AMF3 reference issue, I hope this 
also
solves yours..   

Original comment by evert...@gmail.com on 25 Mar 2008 at 12:31

GoogleCodeExporter commented 8 years ago
The problem was not solved, as we suspected.

The problem is basically that the above request is parsed as a 
SabreAMF_AMF3_Wrapper,
but SabreAMF_CallbackServer does not seem to handle this message anywhere. I 
have
fixed the problem by adding some code to handle a SabreAMF_CallbackServer to
SabreAMF_CallbackServer->exec(). I have attached a diff (SabreAMF.diff).

However, after that problem is tackled, amfphp's browser still fails. So I did 
some
tricks to get the exact same request with the exact same response by both 
AmfPHP and
SabreAMF (attached: gateways.chls). The only difference between the two
reuquest/response pairs is the way the gateway hadnles them. In both cases the 
actual
return value of the service function is the same, which in PHP terms is:

Array
(
    [0] => Array
        (
            [login] => Array
                (
                    [description] => Performs a login attempt for username $username
with password $password.
                    [arguments] => Array
                        (
                            [0] => username - string username
                            [1] => password - string password
                        )

                    [access] => private
                )

            [logout] => Array
                (
                    [description] => Logouts the user. All session data is cleared.
                    [arguments] => Array
                        (
                        )

                    [access] => private
                )

        )

    [1] => Session actions.
)

Which is the format the AmfPHP's browser expects for a describeServer request.

The only difference I can see between the two responses is that AmfPHP seems to
return multiple response bodies, while SabreAMF still returns only one. Other 
then
that the two request/responses pairs appear to be identical.

A

Original comment by amirab...@googlemail.com on 26 Mar 2008 at 2:42

Attachments:

GoogleCodeExporter commented 8 years ago
So this is odd..

It's clear what you're doing in the CallbackServer.diff, you're getting an
AMF3_Wrapper object, and only grabbing the inner data..

However, if you trace all that back a little bit...

The $request variable comes from SabreAMF_Server::getRequests()

That method, in turn, gets its data from SabreAMF_Message::getBodies(), which 
gets it
from the private variable bodies.

That variable is populated after the deserialize() method.. If you look at line 
153
in SabreAMF_Message, you'll see that what you did in CallbackServer, is already 
done
there as well..

The differences in the 2 requests in the charles dump you sent me makes perfect
sense.. The reason you're getting 2 bodies from AMFPHP, is because they 
implemented
onDebugEvents, which doesn't come standard in SabreAMF..

Its not that I don't believe you, but it definitely has me confused.. In any 
case I
feel the SabreAMF_AMF3_Wrapper handling should all happen within 
SabreAMF_Message
(like it pretty much should be right now)

I'm going to use your request and try to copy the exact situation, to see what 
happens..

Original comment by evert...@gmail.com on 26 Mar 2008 at 4:13

GoogleCodeExporter commented 8 years ago
Yes, but the problem is that the wrapper never comes into play. It's not a 
subclass
of SabreAMF_Message, so it is not picked up as an AMF3 message and the 
execution path
just continues to try and handle it like an AMF0 message, which is obvious 
completely
inadequate.

If AmfPHP's browser is sending non-standard messages then it's a different 
debate
whether or not you want to also break the standard. However, I doubt that 
AmfPHP's
browser does that, because it is based on Flex itself, so I'm guessing they 
just use
the library normally.

Original comment by amirab...@googlemail.com on 29 Mar 2008 at 8:50

GoogleCodeExporter commented 8 years ago
Found the issue on 2 places..

Can you give the latest SVN version a shot?

I won't create a release just yet, as I want to do some improvement in the 
general
framework.. The AMF0/AMF3/AMF3+RemoteObject handling is too scattered and 
should be
centralized more

Original comment by evert...@gmail.com on 29 Mar 2008 at 10:00

GoogleCodeExporter commented 8 years ago
Hi,

I had the time to test the latest SVN. The input problem is fixed, the method 
gets
called correctly. thanks for that!

However, the response still isn't displayed in the service explorer. So is it an
explorer bug or a sabreamf one?

anyone got the explorer working with sabreamf?

thanks!!

Original comment by sylvinus on 16 Apr 2008 at 3:53

GoogleCodeExporter commented 8 years ago
Hi Sylvinus,

I looked at the charles session again you sent earlier.. The first thing that 
catches
my eye, is that there's a slight difference between the objects sent back from
amfphp, and SabreAMF.. First thing I would try is matching the returned 
structure
exactly..

The main difference I see are the 'logout' and 'login' objects. Those objects 
are
identified as Mixed Arrays in charles for SabreAMF, but its an Object in the 
AMFPHP
result.

Original comment by evert...@gmail.com on 16 Apr 2008 at 1:50

GoogleCodeExporter commented 8 years ago
The bug that had been identified here has been fixed, but another issue 
mentioned is
not considered a SabreAMF bug and I believe this is due to the fact SabreAMF 
has a
different encoding strategy for certain data-types.. If you still feel this is 
in
fact a bug in SabreAMF, and you're not able to match the exact data-structure 
from
AMFPHP, let me know..

Although SabreAMF's encoding strategy is different, it should provide the 
ability to
encode to every desirable as-type.

Original comment by evert...@gmail.com on 16 Sep 2008 at 10:56