Core Web App

Recently, I was trying to setup Hudu to use SMTP over port 465, but it doesn't seem to support this functionality. Upon referencing documentation, it seems Hudu only supports STARTTLS. STARTTLS is known to be an attack vector. See here https://nostarttls.secvuln.info/ It would be appreciated if Hudu SMTP supported implicit SMTP over 465 instead of requiring STARTTLS over 587.

Hudu already has the ability to check passwords that have been involved in data breaches. It would enhance security if we could check for re-used passwords within both sub accounts and through the organization as a whole.

Please add support for IP address ranges within Hudu’s IP Access Control settings. Additionally, please allow admins to specify IP ranges using standard formats such as: CIDR notation (example: 192.168.1.0/24) IP range notation (example: 192.168.1.10 to 192.168.1.50)

The built in security groups are decent, but we would really benefit with a way to lock down certain components "write" access, such as the "Overview" section, specific KB folders (similar to how Passwords have group access permissions), and/or People having a global section vs client specific.

There are only 6 roles available. However, I would like to be able to break it out more granularly. For example be able to create a role that can create/update/flag documentation, but not share. Allowing custom role creations would likely satisfy a few feature quests here by getting the permissions broken down more granularly and allowing us to choose which permission get applied to the custom role.

We would like to allow one of our clients to access Hudu (without having to add individual users as "Guests" in our M365 tenant), so I converted our SAML Application to be multi-tenant. I am receiving two errors when logging in as a client user: 0="Doesn't match the issuer, expected: < https://sts.windows.net/<msp tenant ID>, but was: < https://sts.windows.net/<client tenant ID>/> 1=Invalid Signature on SAML Response" 0. "Doesn't match the issuer." I believe the documentation below is relevant here, as it explains the additional step that's required when validating issuers for a multi-tenant application. https://learn.microsoft.com/en-us/entra/identity-platform/howto-convert-app-to-be-multi-tenant#update-your-code-to-handle-multiple-issuer-values 1. "Invalid signature on SAML response." Unsure how to validate signatures on multi-tenant SAML responses. Perhaps the multi-tenant Federation Metadata ( https://login.microsoftonline.com/common/FederationMetadata/2007-06/FederationMetadata.xml ) is needed?

If creating a Group with Restrictions -> Core Features -> Share set to False -> User is not able to view the entire Share module (creating a public share, and the current public share link) It would be nice if the toggle for share had two sub settings: View Only Existing Public Share Link for Article Create New Public Share Link For Article

Please add revision history tracking for both Knowledge Base folders and Password folders, similar to the revision history that already exists for assets, KB articles, and passwords.

Often for cybersecurity compliance frameworks organizations are required to produce an asset list. Hudu is the best way to do this if you are truly documenting all of your assets there. The problem is there are many internal/private fields we would not want to show up on an export that we would produce for compliance. Honestly, if we were to export the data for a client who is leaving we wouldn't want all the data we store there to be exposed so it puts us in a situation to either include LESS data in Hudu, or not give an export. Neither are great options. Ideally there should be a way to set a field to whether or not it displays in a PDF export or not (a simple 1/0 switch would be fine here). This way you can produce annual, quarterly, monthly asset lists for clients right out of Hudu without exposing your internal special sauce or data.

It would be nice to ship logs to Huntress SIEM for analysis / archiving.