Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 2 Nächste Version anzeigen »

The Universal Messenger core application running in a Tomcat server offers two interface types on HTTP:

  • The graphical user interface, usually /cmsbs

  • Web services (both built-in and individually built for your project with CSE), usually /cmsbs/rest

Those web services can act as interfaces to other systems but they can also be consumed by front end applications on your web sites. Those public interfaces can be:

  • Tracking for newsletters

  • Newsletter archive or browser view for individual newsletters

  • Forms or JavaScript applications integrated into your website as widgets (e.g. newsletter subscription form, general contact form etc.)

  • REST services consumed by headless web applications

In that case it is necessary to expose those interfaces to the Internet.

Directly exposing /cmsbs/rest and let your website users have access to all services is a very bad idea, especially, but not only, from a security standpoint.

UM REST Proxy

To expose specific web services to the Internet there is a separate web component called “UM REST Proxy”. It is a small Java web application which can run in a separate Tomcat server. It offers extensive configuration options to limit traffic and general availability of individual REST interfaces of the Universal Messenger.

Details: https://www.universal-messenger.de/knowledge-base/intern/doc-en/Administration/REST-proxy.html

Properties and functions

  • Application specific Reverse Proxy or Application firewall

    • It manages only access to REST services offered by the Universal Messenger and only gives access to those REST services which are explicitly allowed (whitelist).

  • Caching static resources so that the Universal Messenger has to answer only as few HTTP requests as possible. 

  • Protection of internal infrastructure (Universal Messenger, databases etc.) from the effects of external (D)DOS attacks 

  • Separation of public and protected API (internet vs. extranet) 

  • Distribute and allocate front-end tasks in a cluster 

Infrastructure

You can have different UM Rest Proxy instances on different web servers, e.g. Intranet vs. Internet or different domains/tenants which all use different interfaces on the UM backend.

Typical configuration

Outmost web server

On your outmost web server or load balancer which handles your website under www.yourwebsite.com add a Reverse Proxy configuration to handle all requests to /p/…

On Apache this would looks like this:

<Location /p/>
    SetEnv proxy-initial-not-pooled 1
    ProxyPass "http://your_restproxy_tomcat:12345/p/"
    ProxyPassReverse "http://your_restproxy_tomcat:12345/p/"
    RequestHeader set x-cmsbs-urlprefix "https://www.yourwebsite.com/p"
    RequestHeader unset x-cmsbs-restproxy-path 
    RequestHeader unset x-forwarded-host 
</Location>
  • Keine Stichwörter