* Initial implementation of a CopyFileInfos function that creates new FileInfo objects copied from provided FileIds with the provided user as the creator and not linked to a post yet. This can subsequently be used to copy existing attachments from another post to attach to a new post without having to re-upload the actual files
* added a unit test for the CopyFileInfos function
* resolving pull request suggestions
deleted test config
fix test config
Dont wipe the session token for plugins
Simplified Tokens; Generate CSRF for other sessions
Remove CSRF from Access Token; Remove Getter/Setter from Context
fix removed setter
remove getcsrf helper from plugin api
enforce csrf only for cookie auth
* plugins: compute bundle hash on load
Use this hash to bust client caches whenever the plugin bundle changes.
* eliminate redundant pluginHandler
* switch to 64-bit FNV-1a
* Fix test
* MM-11065: Allow to search and get archived channels from the API
* Fixing more tests
* Add some unit tests
* Add includeDeleted parameter to session permissions check function
* More test fixing
* Adding archive channels list in channels search
* Add restriction for archived channel edition
* Reverting permissions checks modification
* Changed the query parameter to include_deleted
* Enable search archive channels as true by default
* Adding tests for verify search on deleted channels
* Allowing to override archive channels during the imports
* Fixed test
* Search in archive channels from the API must be explicitly requested
* Removing includeDeleted parameter from GetChannelByName and GetChannelByNameForTeam
* Back to ViewArchivedChannels config
* Fixing tests
* Reverting GetChannelByName parameter
* Add include deleted parameter on GetChannel functions in plugins api
* Fixing tests
* ensure plugin is always shutdown
Once we call `.client.Client()` the plugin has started, and must be shut
down. `newSupervisor` sometimes returned with an error (and without a
reference to the supervisor), leaving the client running indefinitely.
* Clarify the documentation to explain that plugin hooks will not trigger until `OnActivate` returns successfully, and will stop triggering just before `OnDeactivate` is called.
* test for plugin deadlock
* plugin/environment.go: switch to sync.Map
From: https://golang.org/pkg/sync/#Map
> If a goroutine holds a RWMutex for reading and another goroutine might call Lock, no goroutine should expect to be able to acquire a read lock until the initial read lock is released. In particular, this prohibits recursive read locking. This is to ensure that the lock eventually becomes available; a blocked Lock call excludes new readers from acquiring the lock.
The previous `RWMutex` was not safe given that we effectively acquired read locks recursively (hook -> api -> hook). This worked up until we activated or deactivated plugins, tried to acquire a write lock, and the plugin used the API to effectively trigger another hook.
Switching to sync.Map avoids this by divesting the need to lock at all, avoiding the potential for a recursive lock in the first place.
We never actually initialized `log` on apiRPCClient, and it can't log
without making an RPC call anyway, so just switch to logging errors from
the plugin to STDERR instead.
* make GetChannelByName take teamId first
I think it is more natural to accept `teamId`, then `channelName`,
given the pattern followed by other Plugin API methods and even the SQL
Store itself. The App layer seems unusual in accepting `channelName`
first.
This also re-generates the mocks fixing the parameter order for the
recently added `UserStatus` APIs.
* add GetChannelByNameForTeamName
* Support `server`, deprecate `backend` in plugin manifest
This lets us converge on the use of the term `server` everywhere instead
of sometimes `backend` and sometimes `server`. We're still using
`webapp` and will eventually support `mobile` as well.
The plan is actually to rip out these deprecations as part of releasing
5.2, but I want to coordinate the extra additional breakage at the same
time, so for now this is a backwards compatible change.
* fix failing tests
* clean up plugins GoDoc:
- eliminate plugin.NewBlankContext() as unnecessary
- export ValidIdRegex as a string vs. the less readable var
- add/update various documentation strings
- hide everything by default, except where used by client plugins or the mattermost-server. The exception to this rule are the `*(Args|Returns)` structs which must be public for go-plugin, but are now prefixed with `Z_` with a warning not to use.
- include a top-level example to get plugin authors started
This is not a breaking change for existing plugins compiled against
plugins-v2.
* remove commented out ServeHTTPResponseWriter
* update examples to match developer docs
* add missing plugin/doc.go license header
update api mocks
Generated new hooks
ChannelHasJoinedChannel Implementation
User Left Team/Channel Hook; User Joined Team Hook Implementation
Update RPC Client and Mocks
gofmt
go tests fix
Add Config API Methods
codegne
Add Channel Has Been Created Hook
Fix ChannelHasBeenCreated hook
fix missing context param
fix duplicate hooks; remove redudandcy
* Adding blank request context to plugin hooks for future use.
* Rename RequestContext to Context
* Adding context to ServeHTTP and ExecuteCommand
* Fixing import cycle in test.
* disable Supervisor_PluginRepeatedlyCrash
This test is failing sporadically, largely due to the use of a timeout
to verify results. A more robust solution is required.
* disable Supervisor_PluginCrash
This test is failing sporadically, largely due to the use of a timeout
to verify results. A more robust solution is required.
* allow `Wait()`ing on the supervisor
In the event the plugin supervisor shuts down a plugin for crashing too
many times, the new `Wait()` interface allows the `ActivatePlugin` to
accept a callback function to trigger when `supervisor.Wait()` returns.
If the supervisor shuts down normally, this callback is invoked with
a nil error, otherwise any error reported by the supervisor is passed
along.
* improve plugin activation/deactivation logic
Avoid triggering activation of previously failed-to-start plugins just
becase something in the configuration changed. Now, intelligently
compare the global enable bit as well as the each individual plugin's
enabled bit.
* expose store to manipulate PluginStatuses
* expose API to fetch plugin statuses
* keep track of whether or not plugin sandboxing is supported
* transition plugin statuses
* restore error on plugin activation if already active
* don't initialize test plugins until successfully loaded
* emit websocket events when plugin statuses change
* skip pruning if already initialized
* MM-8622: maintain plugin statuses in memory
Switch away from persisting plugin statuses to the database, and
maintain in memory instead. This will be followed by a cluster interface
to query the in-memory status of plugin statuses from all cluster nodes.
At the same time, rename `cluster_discovery_id` on the `PluginStatus`
model object to `cluster_id`.
* MM-8622: aggregate plugin statuses across cluster
* fetch cluster plugin statuses when emitting websocket notification
* address unit test fixes after rebasing
* relax (poor) racey unit test re: supervisor.Wait()
* make store-mocks
* don't report an error on plugin activation if already active
* improved plugin logging events
Log an error when a plugin's ServeHTTP fails, or when it unexpectedly
terminates.
Restart a plugin at most three times, allowing its failure to later
bubble up under the "failed to stay running" status.
* clarified plugin activation/deactivation
Avoid repeatedly activating when any configuration bit changes. Improved
logging.
* constrain plugin ids to ^[a-zA-Z0-9-_\.]+$ and enforce minimum length
Previously, the plugin id was used unsanitized to relocate the plugin
bundle, which allowed writing outside the `plugins/` directory by using
an `id` containing `../`.
Similarly, an empty string was accepted as an id and led to unexpected
error messages.
* remove plugins by manifest path, not id
If the id within the manifest ever diverges from the actual plugin
location, it becomes impossible to remove via the API. Instead, if the
plugin is found by id, remove the path containing the manifest.
* ignore plugins with nil manifests
If a plugin was detected, but had a manifest that couldn't be parsed, it
will be left nil but still be listed among the packages. Skip over these
in most cases to avoid segfaults.
* leverage mlog more effectively for plugins
* build issues
* add CUD support for channel members via plugins
This effectively exposes AddChannelMember, UpdateChannelMemberRoles,
UpdateChannelMemberNotifyProps and LeaveChannel via the plugin API.
It also modifies the semantics of AddChannelMember to explicitly allow
for an empty user requestor, left as such for now via the plugin API.
* change the signature of AddChannelMember to accept a channel id instead of a channel
* plugin sandboxing
* remove unused type
* better symlink handling, better remounting, better test, whitespace
fixes, and comment on the remounting
* fix test compile error
* big simplification for getting mount flags
* mask statfs flags to the ones we're interested in
