Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More →
@mashroom/mashroom-browser-cache
Advanced tools
@mashroom/mashroom-browser-cache - npm Package Versions
Changelog
1.2.1 (November 25, 2019)
- Redis Session Provider: Added cluster support
- Session Middleware: Log error messages of providers (Redis, MongoDB) properly
Changelog
1.2.0 (November 15, 2019)
- Portal: The Angular 8 demo App can now be loaded multiple times on the same page with a different configuration (bootstrap fixed).
- Portal: Added support for sharing resources between portal apps (e.g. vendor libraries or styles).
A shared resource with a given name will only loaded once, even if multiple Portal Apps declare it.
A shared resource can be added like this in the plugin definition:
Check out the demo project here: https://github.com/nonblocking/mashroom-demo-shared-dll{ "name": "Demo Shared DLL App 1", "type": "portal-app", "bootstrap": "startupDemoSharedDLLApp1", "sharedResources": { "js": [ "demo_shared_dll_910502a6fce2f139eff8.js" ] } } - Portal: A remote Portal App which is not reachable for a long time is now unregistered instead of complete removed from the list of remote Apps
- Added MongoDB session provider plugin
- Added Redis session provider plugin
- Portal: Show a proper error if a configured Portal App on a page cannot be loaded (instead of showing nothing)
Changelog
1.1.4 (October 23, 2019)
- Core: Logger instances created via req.pluginContext.loggerFactory('category') share now the context with all other loggers created
from the same request. This can for example be used to output tracing information with each log entry.
The following context properties will be added automatically to each request:
- clientIP
- browser (e.g. Chrome, Firefox)
- browserVersion
- os (e.g. Windows)
- sessionID (if a session is available)
- portalAppName (if the request is related to a portal app)
- portalAppVersion (if the request is related to a portal app) To add additional properties to the logger context use the new logger.addContext() method (e.g. within a middleware). If you want to output context properties with the log entries you could configure the log4js appender like this:
"console": { "type": "console", "layout": { "type": "pattern", "pattern": "%d %p %X{sessionID} %X{browser} %X{browserVersion} %X{username} %X{portalAppName} %X{portalAppVersion} %c - %m" } } - HTTP Proxy: White listed Jaeger, OpenZipkin and W3C Trace Context HTTP headers by default
- HTTP Proxy: Fixed the problem that all requests headers got forwarded to the target, even cookie and other security relevant ones
Changelog
1.1.3 (October 15, 2019)
- Tabify App: Allow to update the title for a specific app id. This is useful for dynamic cockpits where you might want to load the same App multiple times in a tabbed area.
- Portal: Fixed a problem with token highlighting in the add app panel
Changelog
1.1.1 (September 26, 2019)
- WebSocket server now sends keep alive messages to prevent reverse proxies and firewalls from closing the connection
- Portal: MashroomMessageBus.getRemoteUserPrivateTopic() takes now an optional argument username if you want to obtain the private topic of a particular user instead of the "own" (the private topic of the authenticated user)
Changelog
1.1.0 (September 19, 2019)
- Portal: Added two new (optional) security related properties to the default config of portal apps:
- defaultRestrictViewToRoles: Same as the previous defaultRestrictedToRoles but renamed to make its purpose clearer. These roles can be overwritten via Admin App per App instance in the UI.
- restProxy.restrictToRoles: If this is set only users with one of the given roles can access the rest proxy. In contrast to all other permissions the Administrator role has not automatically access.
- Added a provider plugin to support MQTT as external messaging system
- Added a demo portal app to demonstrate remote messaging
- Portal: Added support for remote messaging. Portal apps can now subscribe to server side topics (prefixed with :remote) and communicate with apps on other pages and browser tabs. If the service side messaging is connected to an external messaging system (e.g. MQTT) it is also possible to subscribe and publish messages to the external system.
- Added a Service plugin for server-side messaging that comes with a WebSocket interface which allows sending messages across clients (and browser tabs). Furthermore it be connected to an external messaging system (such as MQTT) via provider plugin.
- Core: Added the possibility to listen on Plugin load and unload events via MashroomPluginService. Useful if you want to cleanup when your plugin unloads or in the rare case where you have to hold a plugin instance and want to get notified about an unload or reload.
- Added a Service plugin to handle WebSocket connections (mashroom-websocket)
- Core: web-app Plugins can now additionally have handlers for upgrade requests (WebSocket support) and for unload
- Core: The Middleware tab in the Admin UI shows now the actual order of the stack (until now the order was just calculated)
Changelog
1.0.94 (August 28, 2019)
- Portal: Made it configurable when the Portal will start to warn that the authentication is about to expire
- Renamed MashroomSecurityProvider.refreshAuthentication() to checkAuthentication()
Changelog
1.0.93 (August 27, 2019)
- Portal: Added configuration property to automatically extend the authentication (so it stays valid as long as the browser page is opened)
- Portal: Removed the "auto-logout" feature, instead the Portal warns now when the authentication is about to expire.
- Decoupled authentication from session, in particular the authentication expiration. This simplifies the implementation for providers like OAuth2. BREAKING CHANGE: The MashroomSecurityProvider interface has been extended.