While working with Xibo API, we experienced some Bugs. The CMS version is 2.1:
1. Wrong start value in response header next-link
The correct order would be
First page (0-10): http://localhost/api/layout?start=0&length=10
Second page (10-20): http://localhost/api/layout?start=10&length=10
Third page (20-30): http://localhost/api/layout?start=20&length=10
However, Xibo’s API skips over the second page.
GET https://xxx.yyy.com/api/layout?length=2&start=0 returns a response with the following header
Link <https://xxx.yyy.com/api/layout?start=4&length=2>; rel="next",
<https://xxx.yyy.com/api/layout?start=0&length=2>; rel="first"
Bug: start is 4, instead of 2. It has been incremented twice for some unknown reason.
Additionally, GET https://xxx.yyy.com/api/layout?start=4&length=2
returns a response with the following header
Link <https://xxx.yyy.com/api/layout?start=8&length=2>; rel="next",
<https://xxx.yyy.com/api/layout?start=2&length=2>; rel="prev",
<https://xxx.yyy.com/api/layout?start=0&length=2>; rel="first"
The prev is correct, however start=8 instead of the expected 6
Even the Xibo documentation has this bug Authentication - Integrate with Xibo | Xibo Digital Signage
2. Swagger documentation doesn’t distinguish between multipart/form-data and application/x-www-form-urlencoded
e.g. PUT https://xxx.yyy.com/api/playlist/widget/{widgetId}/audio only accepts application/x-www-form-urlencoded while POST https://xxx.yyy.com/api/library accepts both.
3. Trailing / in a URL leads to different behaviour
POST https://xxx.yyy.com/api/library/ leads to an error message
{
"error": {
"message": "Seite nicht gefunden",
"code": 404,
"data": []
}
}
while POST https://xxx.yyy.com/api/library (without a trailing slash) works as intended
4. OAuth access_code user needs to a superadmin
This seems to be a direct consequence of the fact that Xibo can only create applications with the All permission. Everything else is not accepted.
5. Xibo library search cannot handle special characters such as ( )
Brackets are surprisingly common characters in file names, and yet Xibo’s library search doesn’t handle them correctly. An example of such a file name is Screenshot (1).png
GET https://xxx.yyy.com/api/library?media=Screenshot%20(1).png will return [ ], in other words, nothing.
However GET https://xxx.yyy.com/api/library?media=Screenshot%20(1) will gladly return the file. Even ``GET https://xxx.yyy.com/api/library?media=Screenshot%20(1).` with a dot will return the file.
It’s not an issue with file name extensions breaking the search, because searching for a previously uploaded index.html works flawlessly
6. Embedded Widgets cannot handle special characters
HTML to Embed
<h1> This works </h2>
<h2> However, this will get cut off right 🦈 where the shark is </h2>
This is because Xibo apparently cannot handle any Unicode astral symbols. Other examples of such symbols are 𝄞, 𝐁, 😀
7. Inconsistent /library return JSON
GET https://xxx.yyy.com/api/library returns a response with a mediaType.
However, when uploading a file using POST, it will return a response without a mediaType (e.g. "mediaType": "image"). Instead it returns a response with a type (e.g. "type": "image").
8. Date format
API is wildly inconsistent with which date format it uses and returns. To make matters worse, it’s undocumented. Apparently when calling PUT https://xxx.yyy.com/api/playlist/widget/${widgetId}/expiry Xibo wants a date in the format Y-m-d H:i:s. This is a rather non-standard date format and using the ISO date format would be a vastly superior choice.
And when getting an expiry date, the API returns a Unix timestamp and apparently suffers from the year 2038-millennium bug.
Also, occasionally, I’ve encountered Xibo returning a date as a string-number such as "1567716614562" instead of 1567716614562
9. Add webpage widget to layout using the API is still not documented
This rather important feature hasn’t been documented since 2016. You have to dig through the Xibo forum to find it.
10. Put playlist item clears some optional parameters
PUT https://xxx.yyy.com/api/playlist/widget/{widgetId} results in a number of optional parameters simply being set to empty values.
e.g. useDuration, effect, speed, backgroundColor will simply be erased. However, duration will stay.
11. No documented way to get a widget
You have to use a PUT call to do what a GET call is supposed to do.
As in, PUT https://xxx.yyy.com/api/playlist/widget/{widgetId} to get a widget
12. Text widget cannot update duration without setting text
Not a bug, but rather sub-optimal API design. You cannot update the duration of a text-widget without also setting the text again.
Form data
duration: 6
useDuration: 1
results in
{
"error": {
"message": "Please enter some text",
"code": 422,
"data": {
"property": "text"
}
}
}
Best regards