No edit summary Tag: 2017 source edit |
No edit summary |
||
| Line 2: | Line 2: | ||
== Embedding support by 3rd party == | == Embedding support by 3rd party == | ||
Does the software actively or | Does the software support embedding actively or through interfaces? Most web-based services today do, but some limit functionality. | ||
* '''Embedding widgets available:''' Does the 3rd party provide some widget code | * '''Embedding widgets available:''' Does the 3rd party provide some widget code that can be used for embedding? In the best case, the 3rd party will provide some snippets that do all the necessary embedding. This is the case with YouTube videos, for example. In this case, we use the Widgets extension to create a wrapper that mostly includes the snippets as they are provided. This is necessary for security reasons. Embeddings are very good for displaying complex content, such as video players, special graphics, dynamic charts, and so on, which require some kind of player. | ||
* '''API provided:''' If the | * '''API provided:''' If the third party provides API access, an extension must be written that calls the API and retrieves the relevant data. This data then needs to be transformed and presented within the wiki. Depending on the complexity of the API, this can be a very simple task or a very challenging one. The API is very good for making complex queries to the 3rd party database and when the focus is mostly on the retrieved data (as opposed to the visualization). | ||
* '''SDK provided:''' Some 3rd parties provide software development kits | * '''SDK provided:''' Some 3rd parties provide software development kits to help build complex applications on top of the software. Using SDKs is the best means when some complex interaction between the wiki and the 3rd party is required, but typically developing such connectors is very time consuming. | ||
== Authentication and access control == | == Authentication and access control == | ||
This is a limiting factor to which of the above ways can be used. | This is a limiting factor to which of the above ways can be used. | ||
* '''Client (browser) based authentication:''' The user | * '''Client (browser) based authentication:''' The user must be logged into the 3rd party system. On the pro side, the application has full control over authentication and access control. On the con side, this can be annoying if there is no single sign-on system in place, as the user will be prompted to log in. | ||
* '''Server side authentication:''' Communication between the 3rd party and the wiki is | * '''Server side authentication:''' Communication between the 3rd party and the wiki is server-side. This means that the server must take control of authentication. In this scenario, communication typically takes place using a proxy user. On the pro side, this means that the wiki user does not have to worry about authentication. On the con side, however, per-user access control becomes difficult to implement. It is possible, though. | ||
== Level of integration == | == Level of integration == | ||
* '''Tease and redirect:''' In some scenarios, an integration wants to | * '''Tease and redirect:''' In some scenarios, an integration just wants to get a user's attention. For deeper interaction, the user is redirected to the 3rd party software. This is the case, for example, when embedding a ticket system number (which simply shows the ticket status, but for any interaction the user must follow the link to the ticket system). | ||
* '''Full read:''' In this scenario, the embedded content should be fully readable, such as | * '''Full read:''' In this scenario, the embedded content should be fully readable, such as video or graphics. No editing is required. | ||
* '''Full interact:''' In this scenario, the full range of interaction should be supported. This is the case in BlueSpice with embedding Draw.io diagrams. | * '''Full interact:''' In this scenario, the full range of interaction should be supported. This is the case in BlueSpice with embedding Draw.io diagrams. | ||
There are several technical ways of embedding content. Mostly, we would try to work with widgets, as long as there is an embedding code or some ''iframe'' solution. | There are several technical ways of embedding content. Mostly, we would try to work with widgets, as long as there is an embedding code or some ''iframe'' solution. | ||
==See also== | |||
*[[Reference:Widgets]] | |||
*[https://www.mediawikiwidgets.org/Widgets_Catalog mediawikiwidgets.org: Widgets_Catalog] | |||
[[Category:Customization]] | [[Category:Customization]] | ||
[[en:{{FULLPAGENAME}}]] | [[en:{{FULLPAGENAME}}]] | ||
[[de:Integration von Drittanbieter-Inhalten]] | [[de:Integration von Drittanbieter-Inhalten]] | ||
Revision as of 15:26, 24 February 2023
Integration of third party content into a wiki page can be achieved in various ways. It depends on several factors:
Embedding support by 3rd party
Does the software support embedding actively or through interfaces? Most web-based services today do, but some limit functionality.
- Embedding widgets available: Does the 3rd party provide some widget code that can be used for embedding? In the best case, the 3rd party will provide some snippets that do all the necessary embedding. This is the case with YouTube videos, for example. In this case, we use the Widgets extension to create a wrapper that mostly includes the snippets as they are provided. This is necessary for security reasons. Embeddings are very good for displaying complex content, such as video players, special graphics, dynamic charts, and so on, which require some kind of player.
- API provided: If the third party provides API access, an extension must be written that calls the API and retrieves the relevant data. This data then needs to be transformed and presented within the wiki. Depending on the complexity of the API, this can be a very simple task or a very challenging one. The API is very good for making complex queries to the 3rd party database and when the focus is mostly on the retrieved data (as opposed to the visualization).
- SDK provided: Some 3rd parties provide software development kits to help build complex applications on top of the software. Using SDKs is the best means when some complex interaction between the wiki and the 3rd party is required, but typically developing such connectors is very time consuming.
Authentication and access control
This is a limiting factor to which of the above ways can be used.
- Client (browser) based authentication: The user must be logged into the 3rd party system. On the pro side, the application has full control over authentication and access control. On the con side, this can be annoying if there is no single sign-on system in place, as the user will be prompted to log in.
- Server side authentication: Communication between the 3rd party and the wiki is server-side. This means that the server must take control of authentication. In this scenario, communication typically takes place using a proxy user. On the pro side, this means that the wiki user does not have to worry about authentication. On the con side, however, per-user access control becomes difficult to implement. It is possible, though.
Level of integration
- Tease and redirect: In some scenarios, an integration just wants to get a user's attention. For deeper interaction, the user is redirected to the 3rd party software. This is the case, for example, when embedding a ticket system number (which simply shows the ticket status, but for any interaction the user must follow the link to the ticket system).
- Full read: In this scenario, the embedded content should be fully readable, such as video or graphics. No editing is required.
- Full interact: In this scenario, the full range of interaction should be supported. This is the case in BlueSpice with embedding Draw.io diagrams.
There are several technical ways of embedding content. Mostly, we would try to work with widgets, as long as there is an embedding code or some iframe solution.
