FWIW user passwords are not related at all to Granite CryptoSupport. Further the CryptoSupport master key is not used in the evaluation of passwords. Passwords are evaluated entirely based on the values in the rep:password property. Repeated SHA256 iterations along with a per-user random salt provid...

XSS is not something dispatcher can protect you against in general. XSS protection must be built into the code which produces the output being returned in response to requests from the users browser. E.g. in JSPs the XSSAPI (https://docs.adobe.com/docs/en/cq/5-6-1/javadoc/com/adobe/granite/xss/XSSAP...

In Oak the user id in events is not guaranteed to be the actual user, events from other cluster nodes is just one scenario where that is true. The other known scenario is when too many events are being generated too fast, in which case multiple events get coalesced without respect for which user gen...

The display you reference 'Groups' for any given authorizable (group or user) shows the groups *they* belong to. The everyone group is special *all* authorizables whether users or groups belong to the everyone group. A group being a member of the everyone group does nothing to change who is a member...