- publishing an event when push is enabled to a 2.3 instance failed with an error instead of blocking
- publishing an event wth the remote instance blocking it due to a sync user sharing group conflict resulted in an exception, handled gracefully now
- Added mangle-sync towards 2.3
- gracefully push non sharing group events in a 2.3 format
- timestamps downgraded by 1 second - upgrading the 2.3 instance should automatically allow a resync of mangled events
- allows for saving an event even if an attribute fails
- logs attributes that fail validation
- same for edit
- add_misp_export updated with the above in mind
- Fixed an issue with the new UUID generation method call in OpenIOC
- Fixed an invalid validation check on the salt key
- Added a note on the server page to make it more obvious that values can be changed by double clicking them
- as discovered and reported by Egidio Romano of Minded Security
- The site admin file upload tool allowed for unrestricted file upload that could lead to RCE
- Fixed the file uploader to be much more restrictive
- removed the interactive terms file upload
Merge and upgrade of several new features
Conflicts:
VERSION.json
app/Controller/ShadowAttributesController.php
app/Controller/TagsController.php
app/Model/AppModel.php
app/Model/Event.php
app/Plugin/SysLogLogable/Model/Behavior/SysLogLogableBehavior.php
- Added logging of failed login attempts
- Added (optional) logging of successful authentications
- admin setting that has to be enabled
- will log all API calls (both HTTP method and target url)
- optional logging of user IP address for all logs
- each log entry created while this setting is enabled will log the IP address of the client
- disabling it also hides the IPs from the interface
- added new IP field for the log search (only if enabled)
- As RichieB2B noted, get_current_user() gets the owner of the script in CentOS / RHEL not the user executing the script (as in Ubuntu)
- Current solution uses posix_getpwuid and posix_geteuid if the php-posix package is installed
- if not, it uses whoami
- for some users the workers appeared to be dead even though the worker processes were functional and started by the correct user
- this was due to access to /proc being blocked by open_basedir directive settings
- added a check and the corresponding view changes to this being the case
Merging all the new changes from master
Conflicts:
VERSION.json
app/Console/Command/AdminShell.php
app/Controller/AttributesController.php
app/Controller/EventsController.php
app/Model/Attribute.php
app/Model/Event.php
app/Model/Log.php
app/Model/Server.php
app/Model/User.php
app/View/Elements/side_menu.ctp
app/View/Pages/administration.ctp
app/View/Users/admin_index.ctp
- Under these distros, php is blocked from seeing concurrently running php processes even under the same user
- instead of running ps, the diagnostic now checks the existance of the pid file in /proc/
- finished preview feature
- can now view events and attributes remotely
- can copy over new event to local instance
- new sync mode (update)
- allows to only pull changes to events that exist locally already
- works well with the manual pull of events, no need to pull events that we didn't manually confirm, but can still update all events that we pulled over
- Fixed an issue with background tasks causing the logging to fail
- reworked connection test showing version numbers of both instances
- also telling the admin whether the sync is compatible or not
- Further refactoring / tweaking of the vent view
- implemented a custom pagination tool for data sets that are not directly taken from teh db
- currently creates a pagination object that mocks CakePHP pagination
- supports the CakePHP pagination view helper
- supports: pagination, sorting, custom filters
- implemented first step of the remote instance browser for admins
- view an index of events on another instance
- filter the events
- uses the new pagination
- still missing:
- remote event view
- fetch event from remote instance
- reworked the event view
- separated API and UI code path
- major speedup for the API!
- cleaner code as there was almost 0 overlap
- discussions and attributes are now loaded separately from the event view
- added after the event view loads via ajax
- cleaner pagination
- attribute pagination now finally allows for sorting
- future improvement (coming soon): Show proposals only filter
- filtering on the attributes in general
- diagnostic tool would throw exceptions because the db session tables are still missing in some older instances
- if a different session handler is used, the test is skipped
- fixed an issue where pushing a single event would fail
- both event and attribute edits via the API work without providing a timestamp. The current timestamp is instead attached
- both event and attribute edits fill the required fields from the data in the database if not supplied (as long as the uuid is found)
- .sql file to add all the new fields / tables
- admin tool to convert the old organisation fields to the new objects
- still missing a cleanup method (to remove the old organisation fields once the conversion is done)
- indexes were not created if they already existed
- this was an issue if a non unique index was present
- also made the process more verbose and added a generic method that deals with index removal
- UUID uniqueness was previously not enforced
- changed the MYSQL.sql file to reflect the changes
- Added upgrade admin tool to remove duplicate events and make the database changes required
- Tweaked the tool for the attribute uuid fix so that it cannot created duplicate keys
- some minor fixes, such as automatically removing eventTag objects on event deletion
- new functionality: Event blacklisting by UUID
- site admins cna enable this feature in the server settings
- enabling the feature will make the required db changes
- any deleted event will automatically get blacklisted
- this prevents deleted events from flowing back from a synced instance
- site admins can manually add UUIDs to the list and remove entries
- fix to UUID duplication issues for attributes
- simply run the admin script and it will regenerate the UUID of attributes that are duplicates, if any such exist
- timestamps/event published status will not be affected
- config.core.php now includes a change that prevents from 404 exceptions being logged
- the sync uses 404s to signal that an event with a given uuid does not exist when negotiating proposal synchronisation
- this causes a dangerously high amount of noise in the logs