[Core] DBUS response prints "server_guid" instead of variable value (Forum)

[admin]

Zie:  http://www.vpcore.nl/forum/viewtopic.php?f=4&t=17 [^]

Bij een succesvolle DBUS authenticatie komt onderstaande XML response terug:

<?xml version="1.0"?>
<response>

<header>

<item_count>1</item_count>
<request_process_time>0.0015</request_process_time>
<request_query_count>9</request_query_count>
<request_result>success</request_result>
<request_result_description>DBUS authentication protocol</request_result_description>
<request_result_id>601</request_result_id>
<request_uri>[POST] login</request_uri>
<vpx_version>1.4.3</vpx_version>

</header>
<items>

<item id="1">

<dbus>OK server_guid</dbus>

</item>

</items>

</response>

De documentatie zegt dat je

<dbus>OK vpx</dbus>

kunt verwachten als antwoord. Het lijkt erop of de naam van de variabele ('server_guid') wordt teruggeven in plaats van de waarde van de variabele.

[Frans]

Parked at MediaMosa X.X

[robert]

This bug can not be fixed because all current applications will depend on this value.

We decided to keep this value and change all references in documentation from 'OK vpx' into 'OK server_guid'.

Frans: can you send me (r.blanker@…) the Webservices-MediaMosa-1.4.3.-EN.odt/doc and Webservices-MediaMosa-1.5.3.odt/pdf in original format (those on mediamosa.org) so we can change it (*not the pdf version, we can not edit those*).

[Frans]

Robert,

Webservices-154.odt (413.3 kB) - added by Frans 0 seconds ago.
Its the only odf I have. The rest is pdf.

[UvA - Tom]

Replying to robert:

This bug can not be fixed because all current applications will depend on this value.

We decided to keep this value and change all references in documentation from 'OK vpx' into 'OK server_guid'.

I believe I submitted this issue some time ago.
I don't think current applications will suffer from fixing this defect. The example in Appendix A in the documentation (version 1.4, page 150) checks for substr($result,0,2) === "OK". Personally I don't like depending on substrings, but it does work whether the dbus response string contains "server_guid" or "vpx". As this is the way it's documented in the example code, current applications will very likely have implemented it this way. And therefore changing "server_guid" will not have any impact.
But there are other ways to check for a valid dbus login. I prefer to do a match on the vpx response code (601 = ERRORCODE_OKAY) as this is more reliable and robust than comparing strings.
Instead of not fixing the issue and changing the documentation to "OK server_guid", please educate people and modify the example code and do a check if "request_result_id" equals 601.
It's not a big deal if you change responses as long as they are clearly documented and communicated.

For reference purpose:
Example response of successful dbus login

<?xml version="1.0"?>
<response>
  <header>
    <item_count>1</item_count>
    <request_process_time>0.0011</request_process_time>
    <request_result>success</request_result>
    <request_result_description>DBUS authentication protocol</request_result_description>
    <request_result_id>601</request_result_id>
    <request_uri>[POST] login</request_uri>
    <vpx_version>1.7.4</vpx_version>
  </header>
  <items>
    <item id="1">
      <dbus>OK server_guid</dbus>
    </item>
  </items>
</response>

[robert]

hi Tom :)

First thanks for your reply and your report.

The OK <value> in DBUS is not 'fixed', so any value, as long its 'something' and always the same is ok by DBUS standard. This code has been recently rewritten (into a php class) for v2 and the same 'bug' was copied on purpose and not fixed for the same reason; it doesn't matter what it returns.

The substr() code in the manual advices the 'OK' value check, although I don't like it either. There is one catch on your solution about the request_result_id == 601. Current release 1.7.4 will return 601 (no errors) even when REJECTED happens in DBUS and returns only != 601 when ERROR type is detected. This behavior has been fixed in v2.2 and will always return 601 when all was OK and error code otherwise (as you would expect). I will still advice checking 'OK' value till we release v2.2 later this year when you can safely check the Mediamosa error code.