First 'official' plugin: a plugin decoding X509 certificate communicated in HTTP headers.
The plugin takes the name of the header in parameter:
And adds decoded field in the HTTP headers tab
It's now easier than ever to check certificates on integration!
The plugin code is freely available here:Â https://gitlab.com/TincaTibo/certificate-decoder-spider-plugin/
The plugin dereferences Park tags to display park name and parkCode.
For the plugin to work, Spider tags must be configured to extract park id from the HTTP requests & responses.
The plugin takes 3 parameters:
The code is available in Flowbird bitbucket repo:Â https://bitbucket.org/parkeon-ondemand/sss-park-tag-enrichment-spiderplugin
The plugin:
/park/{id} if less than 5 parks to resolveAll this in a few lines, many nice patterns to reuse !! :D
The plugin extract Streetsmart rights from JWT token.
The plugin takes 3 parameters:
The code is available in Flowbird bitbucket repo:Â https://bitbucket.org/parkeon-ondemand/sss-token-decoder-spiderplugin/
Configuration components such as the below one already allowed importing settings from spreadsheets by copy pasting in the first cell:
Now, they include an export feature to the clipboard. At the top right, you may copy the settings to the clipboard, including or not the headers:
The output can be pasted to Excel, Google sheet or ...
It can then be saved for later, or edited. Then pasted back:
As requested by Remi L,
In the HTTP Request or Response time, you may chose the format of the payload:
The payload is registered and associated to the request template so that it is remembered and applied for all same requests.
You may see and edit registered association in the HTTP specific settings:
I improved map display to improve the statistic information display over the arrows.
Now the latency of communications is display inside the arrows, with color scale:
This allows quick identification of the longest calls / API in a glance.
In order not to overload the UI, the amount of rows on which to display latency can be set in settings:
With this new feature, the network map displays many information at one glance to identify exceptions:
Nodes and Links tooltips on map have been improved for easier usage.
Details view for Nodes and Links have been enriched with the performance statistics gathered to build the map, and complete list of templates and stats.
When you position a node manually, its position gets locked an remembered on the server.
This wasn't working properly lately, because of the temporal indices used to store the node naming and positions.
Now the positions of nodes is saved in users own settings. Only impacting each users view. The position is saved based on the service name, and kept through reloads and nodes history. Much better. You may easily unlock a position by clicking on the lock, as before.
Previously, when Spider tab was hidden in the browser, the background refresh tasks where still running, but browsers such as Chrome where blocking the network calls and slowing down Javascript timers.
This was generating a lot of error messages when the tab was made visible again.
After some documentation reading, Spider now listens to the event
visibilitychange
to know when it is visible on not, and deactivates background tasks when hidden, to restart them when made visible again.
No more pile of error messages in the morning! :)
I was wondering for some time how to improve Spider usage to add specific features for projects or system being monitored while not coupling Spider code to those systems, such as Streetsmart.
I found a solution on ideas that I pushed on Streetsmart business apps architecture. A solution to extend Spider's UI with plugins.
Like nano frontends that add UI features into various parts of the application.
They are standalone Javascript files, implementing a specific signature depending on the plugin type. These plugins must come with their own manifest file providing metadata for the UI, and parameters definition.
The manifest is loaded in Spider UI, thus registering the plugin.
On the UI features accepting the plugins, they are loaded and called if activated (only then), and the results are injected in the UI.
Plugins are loaded in the Settings details:
Once loaded, they are displayed in the same tab, with various options:
You may:
Each plugin may require one to many parameters to work or adjust its work. Parameters are defined in the plugin manifest.
For now, accepted parameters types are:
Parameters may have a default values and validation constraints, as defined in the manifest. Parameters and loaded plugins are saved in users settings, except for password values. Those are not saved on server side, only locally.
{
"@id": identifier for the plugin
"@version": version,
"@type": type of the plugin, as defined in Spider
"manifest": location of the manifest, for reload
"dist": location of the code
"name": name for the UI
"description": description for the UI
"parameters": [ list of parameters
{
"name": name of the parameter in the UI
"description": description of the parameter for the tooltip
"valueName": name of the parameter expected by the plugin
"valueType": type of input (TEXT, PASSWORD, SELECT)
"valueRequired": boolean
"defaultValue": any
"maxValue": for numbers / later
"minValue":for numbers / later
"multipleValues": if many values may be selected
"stepValue": if values are generated from min to max
"valueMaxLength": max length if string
"valueMinLength": min length if string
"valuePattern": regex if string
"optionValue": [ list of possible options for selects
{
"label": string to display
"value": any
}
],
"onlyOptionValuesAllowed": if select accepts unknown values
}
]
}
{
inputs: {},
parameters: {},
callbacks: {setXXX, onShowInfo, onShowError, onShowWarning },
libs: {React}
}
When called, the plugin is called with the above signature:
async function myOwnPlugin({
inputs: {},
parameters: {},
callbacks: {setXXX, onShowInfo, onShowError, onShowWarning },
libs: {React}
}){
...
}
function plugin(props){
myOwnPlugin(props).catch(e => {
props.callbacks.onShowError('myOwnPlugin: Could not work!');
console.log(e);
});
}
plugin\['@id'\] = 'my-own-plugin';
plugin\['@type'\] = 'http-headers-decode-plugin';
plugin\['@version'\] = '1.0'
if(window.spiderPlugins){
if(!window.spiderPlugins.find(p => p\['@id'\] === plugin\['@id'\])){
window.spiderPlugins = \[...window.spiderPlugins, plugin\]
}
}
else{
window.spiderPlugins = \[plugin\]
}
These plugins allow decoding HTTP headers, in request or in response, to reveal their inner data.
This was the original plugin need/idea: decoding Streetsmart rights that are compressed inside the JWT token.
{
inputs: {part, header, value},
parameters: {env, login, password},
callbacks: {setDecodedHeaders, onShowInfo, onShowError, onShowWarning },
libs: {React}
}
The plugin is called for each header.
setDecodedHeaders callback expects an array of objects with this structure:
{
key: String, label to display in the UI
value: Any, value to display
format: String, format of the value
decoded: Boolean, whether or not the header is decoded (gray background in the UI)
}
This plugin extends the tag extraction feature by allowing to dereference / enrich a tag from data of your own system and inject these in the UI.
For instance, a tag could extract the city id of the client of the requests, and get the city name from the system under monitoring. Then filtering becomes easier, and Excel extract, statistics and grid becomes more meaningful.
{
inputs: {name, values, mode},
parameters: {basePath, login, password},
callbacks: {setDecodedTags, onShowInfo, onShowError, onShowWarning },
libs: {React}
}
The plugin is called:
Depending on the call, the output is requested in REACT components mode (grids and details) or in TEXT mode (Excel, filters)
Expected output expects an array of decoded values, in the same order, without holes as the values array input.
Output must be sent both:
Resolving parks names:
An http-headers-decode-plugin plugin example is available in https://gitlab.com/TincaTibo/certificate-decoder-spider-plugin/.
It may be reused and extended at will.
Before, when starting Spider, the timelline was computing the oldest and newest data of the Whisperer to set the starting range of the Timeline.
This query was costly on Elasticsearch side, as it required to load and search on all indices. Which, in the end, generated some timeouts the first times.
I changed the process, and now, the default timeline range is set to current day for realtime whisperers, and computed to min and max only for upload type ones.
To accomodate this new process, you may now zoom out on the timeline from the start, until you reach some defined limit or until you're tired ;)
Less timeouts, faster startup, better UX. Happy zooming and sliding !!
When opening a JSON-LD communication, you are allowed to choose another view to see it.
Thanks to the UI refactoring, it costed me almost nothing to provide an edit feature to these settings in the HTTP settings panel (and I had to find stuff to put there ;) ).
