Adds XEP-0363 functionality to Openfire that allows compliant clients to exchange files

License: Apache License 2.0

HTML 21.92% Java 78.08%

openfire-httpfileupload-plugin's Introduction

Openfire HTTP File Upload Plugin

Adds XEP-0363 functionality to Openfire that allows compliant clients to exchange files.

CI Build Status

Reporting Issues

Issues may be reported to the forums or via this repo's Github Issues.

Overview

The HTTP File Upload plugin adds functionality to Openfire that allows compliant clients to exchange files. The protocol implemented by this plugin is defined in XEP-0363: HTTP File Upload.

Note: This plugin requires the HTTP bind option in Openfire to be enabled: Server -> Server Settings -> HTTP Binding

Installation

Copy httpfileupload.jar into the plugins directory of your Openfire installation. The plugin will then be automatically deployed. To upgrade to a new version, copy the new httpfileupload.jar file over the existing file.

Using the Plugin

After installation, the functionality provided by the plugin is automatically available to clients. While exchanging files, the plugin by default stores the files that are being transferred in a temporary directory that is removed when Openfire is shut down. The content of this directory is purged when its total size is larger than the remaining disc space.

Configuration

Most configuration options can be controlled by two different properties. Apart from using regular Openfire properties, controlled in the Openfire admin console, XML properties can be used. XML properties are properties stored in the openfire.xml file.

Regular properties are stored in the database. This will ensure that a property value is equal on all servers in a cluster of Openfire servers. When it is desirable to have a property values that are different on each server, an XML property can be used (as the content of the openfire.xml file can be different on each server).

When both a regular and an XML property is defined, then the XML property value will take precedence.

Storage of data on filesystem

XML property: plugin.httpfileupload.serverspecific.fileRepo
System Property: plugin.httpfileupload.fileRepo

By default, the plugin will store all uploaded files in a temporary directory that is provided by the Operating System. This directory is configured to be deleted, after Openfire quits. Some Operating Systems are known to periodically purge these temporary directories, which is another potential source of data loss. This plugin can be configured to use any other directory for data storage, by providing the path for that directory in either property listed above. Note that the directory is expected to exist (this plugin will not attempt to create it if it is missing). Be sure that the process owner of the Openfire process has enough permissions to read and write in that directory.

Maximum file size

XML property: plugin.httpfileupload.serverspecific.maxFileSize
System Property: plugin.httpfileupload.maxFileSize

To configure the maximum allowable file size to be uploaded by clients, the property defined above can be set to a value in bytes. If not set, a default value is used. To disable the file size limitation, set a property to a value of -1.

Announced web endpoint

The plugin will send URLs to the client that are to be used to upload or download data. To following properties can be used to control the composition of the URLs that are generated.

To change the HTTP server protocol from the default value of "https" to "http" for example, use these properties:

XML property: plugin.httpfileupload.serverspecific.announcedWebProtocol
System Property: plugin.httpfileupload.announcedWebProtocol

To change the HTTP server hostname from the default value used by Openfire, use these properties:

XML property: plugin.httpfileupload.serverspecific.announcedWebHost
System Property: plugin.httpfileupload.announcedWebHost

To change the HTTP server port from the default value (7443) used by Openfire, use these properties

XML property: plugin.httpfileupload.serverspecific.announcedWebPort
System Property: plugin.httpfileupload.announcedWebPort

To change the web context root as announced to clients from the default value (/httpfileupload) used by use these properties:

XML property: plugin.httpfileupload.serverspecific.announcedWebContextRoot
System Property: plugin.httpfileupload.announcedWebContextRoot

ClamAV Malware Scanner Integration

The plugin can be integrated with an external malware scanner (read more below). These properties are used for that.

To enable or disable the integration, use this property. When the ClamAV daemon cannot be reached while the feature is enabled, all file uploads will be rejected.

System Property: plugin.httpfileupload.clamavEnabled

Controls the host that is used to integrate with an external (third-party) ClamAV malware scanner daemon.

System Property: plugin.httpfileupload.clamavHost

Controls the port that is used to integrate with an external (third-party) ClamAV malware scanner daemon.

System Property: plugin.httpfileupload.clamavPort

Defines the duration (in milliseconds) after which Openfire giving up trying to establish a TCP connection to the ClamAV scanner daemon.

System Property plugin.httpfileupload.clamavConnectionTimeout

Scanning for Malware

To facilitate virus scanning, you can configure the application to use ClamAV. ClamAV is a third-party, open source (GPLv2) anti-virus toolkit, available at www.clamav.net

To configure this application to use ClamAV, install, configure and run clamav-daemon, the scanner daemon of ClamAV. Configure the daemon in such a way that Openfire can access it via TCP.

Note: ClamAV is configured with a maximum file size. Ensure that this is at least as big as the maxFileSize that is provided as an argument to the HTTP File Upload Plugin.

Then, configure the HTTP File Upload plugin the clamavHost and clamavPort arguments as described in the Configuration paragraph. When these are provided, the application will supply each file that is being uploaded to the ClamAV daemon for scanning. A file upload will fail when the ClamAV daemon could not be reached, or, obviously, when it detects malware.

While malware scanning can offer some protection against distributing unwanted content, it has limitations. Particularly when the uploaded data is encrypted, the scanner is unlikely able to detect any malware in it.

When using in an Openfire cluster

Special consideration needs to be given to the deployment of this plugin in a cluster of Openfire instances. This section outlines the main concerns.

Background: how clients interact with the servers

Unlike most other XMPP-related functionality, this 'HTTP File Upload' functionality uses an additional data path: not only is the XMPP connection itself used; HTTP requests are also made. The HTTP protocol is used to upload and download data. The URLs for these interactions are sent over the XMPP data channel.

In a typical scenario, a client that wants to send a file requests an 'upload slot' through XMPP. When assigned a slot, its URL (as well as other metadata) is returned to the client by the server. Using this information, the client will then upload the data using an HTTP PUT request. After the upload has succeeded, the client will send, over XMPP, send the URL to the intended recipients of the data. Their clients will receive that URL (over XMPP) and subsequently perform an HTTP GET request to download the data from the web server.

Configuration A: Using multiple service endpoint addresses

When each of the Openfire cluster node servers is connected directly to the internet, accessible to clients through their fully qualified domain name, then no configuration might be needed to make HTTP File Upload functionality available on all cluster nodes, for all clients.

Option 1: Each Openfire manages a unique set of data

Diagram illustrating option 1: each Openfire uses its own data store.

pros & cons: This solution requires no configuration, provides adequate scalability, but does not offer much data redundancy or flexibility in network architecture.

Since version 1.2.0 of this plugin, the definition of a Slot is shared across all XMPP cluster nodes. This slot defines the endpoint addresses to be used by the uploader, as well as the recipients of the data.

In the scenario described by this configuration option, each Openfire cluster node will issue slots that contain endpoint URLs that are specific to the server that issued the slot. This means that the upload, as well as all downloads, will be directed to URL on that same server.

Configuration B: Using one service endpoint address

In certain environments it is undesirable or unpractical to expose more than one endpoint URL to chat clients. This is frequently the case when the network architecture includes a load balancer. For this or other reasons, it might have been necessary to reconfigure the 'announced' endpoints (using the configuration options defined in the Configuration paragraph of this document) to use the same endpoint address for all requests.

Option 2: Use only one server for file upload/download

Diagram illustrating option 2: One Openfire used for all file storage.

pros & cons: This solution is typically easy to configure, but provides poor redundancy and scalability.

In this scenario, the singular endpoint address could be mapped to exactly one Openfire cluster node. This can be achieved by directly mapping the 'announced' endpoint details to the address of one of the Openfire nodes, (as described in the Configuration paragraph of this document) or by configuring the load balancer to 'balance' the traffic to just one of the nodes.

Option 3: Use every cluster node for file upload/download

Diagram illustrating option 3: Cluster uses centralized file storage.

pros & cons: More complex to configure, but provides better redundancy and scalability.

When a singular endpoint address is used, then this option typically involves a load balancer that distributes the HTTP requests over all cluster nodes. This comes with some complexities:

It is hard to ensure that the cluster node used by the XMPP connection of the client sharing/uploading the data is the same cluster node used when performing the HTTP upload.
It is often impossible to guaranteed that HTTP requests made by intended recipients of the uploaded data end up at the same cluster node as the one that was used to upload the data to.

When using this configuration option, it should be assured that every XMPP cluster node can fulfill HTTP upload and download requests for all slots.

Since version 1.2.0 of this plugin, the definition of a Slot is shared across all XMPP cluster nodes. To ensure that all data is accessible, all cluster nodes should use the same shared network folder for file storage. This network folder should be available on the filesystem of each of your Openfire servers, using the same path name. This plugin should be configured to use this directory for data storage, by using the plugin.httpfileupload.fileRepo property, as described in the Configuration paragraph of this document.

Realisation of a shared network folder is likely highly specific to the operating system used for your Openfire servers, and is out of scope for this document.

Attribution

Icons made by Smashicons from www.flaticon.com is licensed by CC 3.0 BY.
Diagrams created on diagrams.net/draw.io.

openfire-httpfileupload-plugin's People

Contributors

Stargazers

Watchers

Forkers

guusdk gregdthomas rrze-pp nsobadzhiev isabella232 akrherz makson4iik fishbowler seanpm2001 annovanvliet

openfire-httpfileupload-plugin's Issues

What happens when the file storage path becomes unavailable?

This behaviour in the HTTP File Upload plugin is unknown.

If the path is misconfigured, or is configured to a transient location (e.g. network storage), what does the plugin do when it cannot write the file upon file upload?
What should it do?

Update to HTTP File Upload Component to version 1.4.0

https://github.com/guusdk/httpfileuploadcomponent/releases/tag/v1.4.0

HTTP File Upload plugin should delete files as said in documentation

...Migrated from Ignite Jira OF-1459...

reported by @wrooot

Have only tested this on Windows, not sure what happens on other platforms. Plugin's readme states that files will be deleted from the temp folder on the server after Openfire is turned off or when server runs out of space. On Windows i have found location of temp folders (if running with a regular user: C:\Users\User\AppData\Local\Temp\xmppfileupload_number, if running as a service C:\Windows\Temp). In both running modes temp files are not deleted when Openfire is restarted. Haven't tested if Openfire will try to delete them when server runs out of space. But it seems that it was a presumption that OS will handle this on its own. Windows is often not deleting files in Temp folders for a long time or ever. So in this case server can run out of space and even in that case might not delete them automatically.

We should at least clarify the readme on that. Ideally there should be a mechanism for Openfire to clean these files.

Add support for (virus)scanning uploaded content

Files that are uploaded by clients should be scanned (for viruses, malware, etc).

One idea is to provide an integration with a virus scanner, such as the open source ClamAV scanner.

Default maxFileSize value

To configure the maximum allowable file size to be uploaded by clients, the property plugin.httpfileupload.maxFileSize can be set to a value in bytes. If not set, a default value is used.

So where default value comes from? And what is this value?

Cannot upload files with Padé or IM via httpupload

Cannot upload file to OF via httpfileupload plugin version 1.13

Instance versions : OF 4.6.0 httpupload plugin 👍 Padé 1.3.0

I use httpupload on many configs without problems but on this specific server the FDQN name is not equal to the top XMPP Domain. 2 SRV records are added at the top DNS level.
Error mess in logs i have in logs

2021.02.03 13:44:34 INFO  [pool-2413-thread-3]: nl.goodbytes.xmpp.xep0363.Component - Entity '[email protected]/pade-undefined-v6.0.0-Chrome88Linux-113046287' obtained slot for 'pic10.jpg' (1235312 bytes). PUT-URL: https://chat.conecto.com.br:3443/httpfileupload/11a867ef-3343-41f1-8b5b-67d6b12756b7/pic10.jpg GET-URL: https://chat.conecto.com.br:3443/httpfileupload/11a867ef-3343-41f1-8b5b-67d6b12756b7/pic10.jpg

In err.log

2021.02.03 13:44:22 org.jivesoftware.openfire.websocket.XmppWebSocket - Error detected; session: WebSocketSession[websocket=JettyAnnotatedEventDriver[org.jivesoftware.openfire.websocket.XmppWebSocket@7b3250c2],behavior=SERVER,connection=WebSocketServerConnection@6f5a29d3::DecryptedEndPoint@e3a464c{l=/172.17.0.5:3443,r=/94.103.99.221:42504,CLOSED,fill=-,flush=F,to=54787/300000},remote=WebSocketRemoteEndpoint@70182e78[batching=true],incoming=JettyAnnotatedEventDriver[org.jivesoftware.openfire.websocket.XmppWebSocket@7b3250c2],outgoing=ExtensionStack[queueSize=0,extensions=[permessage-deflate],incoming=org.eclipse.jetty.websocket.common.extensions.compress.PerMessageDeflateExtension,outgoing=org.eclipse.jetty.websocket.common.extensions.compress.PerMessageDeflateExtension]]

Put & Get URL looks fine.

I have defined the following properties :

I have many servers running with this but always with FDQN=Servername=Domain , this is the only difference

Any option to analyse what is going wrong ?
No clue if it is a bug or if it is a question of config

Any help or hint will help

Thx in advance fot your inputs

Add documentation for configuration in a clustered environment

By default, this plugin can't work in a properly clustered environment, since the temporary file store will be node-specific.

Add a clustering specific section to the docs to talk about a shared file store.

Slot manager should be cluster-aware

This plugin hands out a 'slot' to a user that expresses intent to upload a file. This slot holds details on how to update.

When an upload is performed, the attempt is checked against the list of slots that have been handed out. When no match is found, the upload is rejected.

In a cluster, each Openfire node maintains its own list of slots. They have no knowledge of slots available on other cluster nodes.

In a cluster, a load balancer is frequently used. For XMPP data, all requests from a session need to end up with the same cluster node. For XMPP TCP connections, this will mostly be the default case (as all traffic is transmitted over the same, long-lived TCP connection). For BOSH, the load balancer is configured to be 'sticky'.

HTTP file upload introduces data interaction 'outside' of the XMPP channel: regular HTTP requests (PUT and GET) are used. Even if load balancers are configured to be 'sticky', making them 'sticky' in the sense that HTTP requests end up on the same cluster node as where the XMPP session is connected to.

To facilitate scenarios where a load balancer is used, all Openfire cluster nodes should be aware of all slots managed on every cluster node.

Server returns 500 error on upload. Fixed by restarting openfire service but problem keeps appearing later.

Using OpenFire 4.6.4, HTTP File Upload 1,1.3, on Windows Server 2016.
I'm using a converse.js client to upload files in the chat. Almost always it's succesful, however sometimes the response from the server is a 500 error. In the openfile logs, under the "All" tab, I see lines like:

2021.09.06 02:03:37 nl.goodbytes.xmpp.xep0363.Component - Entity '[email protected]/converse.js-44692399' tries to obtain slot.
2021.09.06 02:03:37 nl.goodbytes.xmpp.xep0363.Component - Entity '[email protected]/converse.js-44692399' obtained slot for 'DSC5659.jpg' (1741635 bytes). PUT-URL: https://chat.xxx.com:7443/httpfileupload/0f341d6d-564e-45d3-b0a2-1648f6f25450/DSC5659.jpg GET-URL: https://chat.xxx.com:7443/httpfileupload/0f341d6d-564e-45d3-b0a2-1648f6f25450/DSC5659.jpg
2021.09.06 02:03:37 nl.goodbytes.xmpp.xep0363.Servlet - Processing PUT request... (XX.XX.112.23 submitting to /httpfileupload/0f341d6d-564e-45d3-b0a2-1648f6f25450/DSC5659.jpg)
--- nothing else after about the upload

In the "Warn Tab"

2021.09.06 02:03:37 org.eclipse.jetty.server.HttpChannel - handleException /httpfileupload/0f341d6d-564e-45d3-b0a2-1648f6f25450/DSC5659.jpg java.nio.file.NoSuchFileException: C:\Windows\TEMP\xmppfileupload3257014815371578219\0f341d6d-564e-45d3-b0a2-1648f6f25450

The problem is that if I start getting these errors, then they appear indefinitely on every upload. However problem is fixed immediately if I restart the openfire service.

For example, if I restart the service, the upload works fine, and the logs are instead:

2021.09.06 02:08:13 nl.goodbytes.xmpp.xep0363.Servlet - Processing PUT request... (XX.XX.112.23 submitting to /httpfileupload/8c8018b8-1e1b-4ad3-bb68-4fa95a9293ec/DSC5659.jpg)
2021.09.06 02:08:14 nl.goodbytes.xmpp.xep0363.Servlet - ... responded with CREATED. Stored data from the request body in the repository.
2021.09.06 02:08:15 nl.goodbytes.xmpp.xep0363.Servlet - Processing GET request... (XX.XX.112.23 requesting from /httpfileupload/8c8018b8-1e1b-4ad3-bb68-4fa95a9293ec/DSC5659.jpg)
2021.09.06 02:08:15 org.jivesoftware.util.cache.CacheFactory - Created cache [org.jivesoftware.util.cache.DefaultLocalCacheStrategy] for Sequences
2021.09.06 02:08:15 nl.goodbytes.xmpp.xep0363.Servlet - ... responded with OK and included the data in the response body.

Any hints on how to fix this problem? After each service restart, the uploads work again for perhaps 24 hours, until this problem starts appearing again. I have checked permissions on c:\windows\temp, and this is not the problem.

Security Access to uploaded files & choice of folder to keep & manage files after OF restart

Hello,

httpupload is uploading file in a public area. If link to file is found, anyone can access it. Ideally we should have an option to restrict file access to signed OF users only to provide a better security with uploaded files. This option could be activated or not as we need a public access in some cases.
For storage location if a specific folder could be specify it would be helpfull. No erase on restart and ideally possible file management : no erase ; erase when max is reached, erase daily, weekly...

I understand that it is not an issue but rather enhancement suggestions. If it could be added it would be Great :)

Claude-

maven pom.xml file needs to be updated

I have not got my head around the new maven configuration for plugins. I used a custom version of my own to build a jar file in order to test. Can someone help please

When using non-encrypted scheme, default to non-encrypted port

When configuring http as the value for plugin.httpfileupload.announcedWebProtocol while plugin.httpfileupload.announcedWebPort remains unconfigured, the default value for plugin.httpfileupload.announcedWebPort should be the unsecured port of BOSH, not the secured port, which now is the hard-coded default.

GET URL opens directly in browser, download button missing

I'm encountering an issue with the Openfire HTTP File Upload plugin(1.3.0). When accessing a file through the GET URL generated by the plugin, the browser opens the file directly instead of displaying a download button.

Here are the details of the issue:

Steps to reproduce:

Upload a file using the plugin.
Access the generated GET URL for the uploaded file.
Expected behavior: The browser should display a download button, allowing the user to save the file.
Actual behavior: The browser opens the file directly, often displaying the content inline.

I checked but not able to find any configuration where I can define the content type or content-disposition header to make it downloadable.

I would appreciate it if you could investigate this issue and suggest potential solutions or workarounds. If there are configuration options to control download behavior, please provide guidance on how to access them.

Allow content-security-policy headers to be defined

The specification suggests that content-security-policy HTTP headers are added to GET requests.

Fix API incompatibilities with upcoming Openfire 4.8

Openfire 4.8 has removed some API that is still being used by this plugin. We need a new build of the plugin that doesn't use this API, so that at least one version of the plugin remains available to be used for the future version 4.8 of Openfire.

One API change (possibly not the only one) is usage of org.jivesoftware.openfire.http.HttpBindManager.getHttpBindSecurePort

Assembly jar name does not match nomenclature for other ignite openfire plugins

Running mvn -B package yields a artifact of httpfileupload-openfire-plugin-assembly.jar. This all-lowercase-name does not match the nomenclature of the pom.xml:project:artifactId being camel case and thus matching the other ignite openfire plugins. This causes our Github Actions automation to fail as it looks for a file named httpFileUpload-openfire-plugin-assembly.jar.

I am unsure of the lowest friction thing to do in this case.

Ignite website still distributes version 1.1.0

...Migrated from Ignite Jira OF-1659...

Http file upload component has version 1.2.0 released. Current plugin for Openfire only has 1.1.3 included. Plugin should be updated.

Use SystemProperty to replace old style properties

This plugin should use the SystemProperty class to replace the old JiveGlobals-based property interaction. The newer implementation comes with a few nice features that this plugin will benefit from.

Authentication for GET and PUT url generated by httpfileupload

I’m working on configuring Openfire HTTP File Upload and I’m looking for guidance on how to properly authenticate GET and PUT requests for file download and upload URLs. Specifically, I want to ensure that only authenticated users can access these URLs and perform the corresponding operations. What are the best practices or recommended approaches for implementing authentication in Openfire HTTP File Upload?

Does HTTPFileUpload provide any default configuration to provide some authentication?

Any tips or insights would be greatly appreciated.

How to configure HTTPS domain names

The online environment does not use IP. If you want to use the HTTPS domain name instead of IP and port, how to configure it? The generated file URL is incorrect
https://192.168.1.100:7443/httpfileupload/xxxxxxx.png =>https://domain.com:7443/httpfileupload/xxxxxxx.png,
instead of https://domain.com/httpfileupload/xxxxxxx.png

Byte range request for any uploaded file on Openfire is not enabled

Hi We are using Openfire 4.5.1

We are trying to generate thumbnail image of any uploaded video/file in Openfire xmpp server from our iOS client app. The code that we are using to generate thumbnail image it requests byte range of the selected url. But byte range request is not enabled in Openfire server for any file. How can I enable byte range request in Openfire server.

Accept-Ranges: bytes

How make effective change of port using property plugin.httpfileupload.announcedWebPort

Already posted some questions in guusdk/httpfileuploadcomponent#26 regarding issues I have to make effective the change of port when using the plug-in plugin.httpfileupload.

I changed the default value 7443 to 7444 using the property plugin.httpfileupload.announcedWebPort in my Openfire environment.
Unfortunately, this port is not opened (even after restart of Openfire). Consequently, I can't upload file from my Converse.js client.

My question here is quite simple:
How can I make effective the change of port ?

Many thx for your help :)
KR
ErwanF

Announced URL configuration should be cluster-node specific

This plugin will announce URLs on which data is to accessed via HTTP. By default, this will default to the server's hostname (as configured in Openfire), and the BOSH port on which the servlet in this plugin binds.

Through the magic of networking, load balancing and proxies, it is often desirable to modify the URLs that are sent to the clients: for example, to include a different hostname. This plugin facilitates that through various configuration properties.

In Openfire, a property value, by default, is saved in the database, which is shared by all servers in a cluster. This means that a value is used by all cluster nodes. For the HTTP interaction implemented in this plugin, this can be undesirable: it can be desirable to have a unique URL for each cluster node (that is not the default URL).

To facilitate this, the plugin should be configurable in a manner that is specific to a cluster node.

What happens when the file storage volume is full?

This behaviour in the HTTP File Upload plugin is unknown.

If the configured destination path is full (be it local or remote), what currently happens? Is it even detectable?
What should happen?

Does not work

I've tried 1.1.1-SNAPSHOT and it does not work.
At least with Pix-Art Messenger. Stable 1.1.0 version works.
Client gets PUT url and then failed.

where should I set plugin.httpfileupload.announcedWebProtocol?

Hi,

I tried to do this in the openfire.xml file

<plugin>
    <httpfileupload>
      <announcedWebProtocol>http</announcedWebProtocol>
    </httpfileupload>
  </plugin>

not sure if this the right thing to do

ClassCastException when running v1.2.0 in cluster

This is likely servers having restarted the plugin without a reboot. References to the old classloader are retained in Hazelcast, causing this. Possible work-around: restart all servers in the cluster.

2022.12.13 10:53:25 WARN [Jetty-QTP-BOSH-134321]: org.eclipse.jetty.server.HttpChannel - /httpfileupload/zHLXVTanzG2DPH-RXN8aXRTZDTk/KbdNG2PWT2ykV9kCiF6j9Q.jpg
java.lang.ClassCastException: nl.goodbytes.xmpp.xep0363.Slot cannot be cast to nl.goodbytes.xmpp.xep0363.Slot
    at org.igniterealtime.openfire.plugins.httpfileupload.OpenfireSlotProvider.consume(OpenfireSlotProvider.java:62) ~[?:?]
    at nl.goodbytes.xmpp.xep0363.SlotManager.consumeSlotForPut(SlotManager.java:92) ~[?:?]
    at nl.goodbytes.xmpp.xep0363.Servlet.doPut(Servlet.java:175) ~[?:?]
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) ~[javax.servlet-api-3.1.0.jar:3.1.0]
    at nl.goodbytes.xmpp.xep0363.Servlet.service(Servlet.java:78) ~[?:?]
    at org.igniterealtime.openfire.plugins.httpfileupload.CORSServlet.service(CORSServlet.java:55) ~[?:?]
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) ~[javax.servlet-api-3.1.0.jar:3.1.0]
    at org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1450) ~[jetty-servlet-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[jetty-servlet-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550) ~[jetty-servlet-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602) ~[jetty-security-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1434) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501) ~[jetty-servlet-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1349) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:59) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633) ~[jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380) [jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) [jetty-server-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [jetty-io-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [jetty-io-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) [jetty-io-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) [jetty-util-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) [jetty-util-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) [jetty-util-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) [jetty-util-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:386) [jetty-util-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) [jetty-util-9.4.43.v20210629.jar:9.4.43.v20210629]
    at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) [jetty-util-9.4.43.v20210629.jar:9.4.43.v20210629]
    at java.lang.Thread.run(Thread.java:750) [?:1.8.0_342]

Fix Maven build

To build plugins for Openfire 4.3.0 pom.xml should include repositories tags pointing to Archiva. If plugin has pages in Admin Console, web.xml should also be added.

For references:
igniterealtime/openfire-clientControl-plugin#11

Update to HTTP File Upload Component to version 1.3.0

See https://github.com/guusdk/httpfileuploadcomponent/releases/tag/v1.3.0

This release replaces UUID usage (to identify uploads).

Wrong links in the changelog

Having component and actual plugin in different repos and as separate projects makes it easy to mix up things.

Release 1.1.1 fails (unless used on root context).

I have just upgraded httpFileUpload plugin to version 1.1.1 and it has stopped working. When trying to send an image, I'm just getting "delivery failed" every time. After switching back to 1.1.0, everything works again.
Client I was testing it with is Conversations version 2.5.12+pcr (on Android 9)

Unloading the plugin does not cause the PluginClassLoader to be garbage collected

The classes of an Openfire plugin are loaded through a dedicated instance of PluginClassLoader. It is expected that this instance is no longer used/references and thus eligible for garbage collection immediately after the plugin is unloaded.

For the HTTP File Upload plugin, this does not seem to be the case. Its PluginClassLoader remains in memory indefinely (or at least ~10 minutes) after the plugin gets unloaded.

Initial heap dump analysis shows that there's a timer task in AbstractFileSystemRepository that might keep a reference alive.

Update component to v1.7.0

https://github.com/guusdk/httpfileuploadcomponent/releases/tag/v1.7.0

This brings an important security improvement.

What happens to the plugin during clustering interruptions?

This behaviour in the HTTP File Upload plugin is unknown.

Clustering is a network facility, and will be interrupted at some point.
How does the plugin behave when clients can talk to a cluster node, but clustering isn't available?
Is this different when a client can reach both servers (rather than just one)?

Allow announced URLs to be HTTP instead of HTTPS

The URLs that the plugin sends to peers (on which data can be posted or retrieved) currently is HTTPS-based, hard-coded.

It should be possible to configure HTTP (unsecured) URLs.

igniterealtime / openfire-httpfileupload-plugin Goto Github PK

openfire-httpfileupload-plugin's Introduction

Openfire HTTP File Upload Plugin

CI Build Status

Reporting Issues

Overview

Installation

Using the Plugin

Configuration

Storage of data on filesystem

Maximum file size

Announced web endpoint

ClamAV Malware Scanner Integration

Scanning for Malware

When using in an Openfire cluster

Background: how clients interact with the servers

Configuration A: Using multiple service endpoint addresses

Option 1: Each Openfire manages a unique set of data

Configuration B: Using one service endpoint address

Option 2: Use only one server for file upload/download

Option 3: Use every cluster node for file upload/download

Attribution

openfire-httpfileupload-plugin's People

Contributors

Stargazers

Watchers

Forkers

openfire-httpfileupload-plugin's Issues

Recommend Projects

Recommend Topics

Recommend Org