Feature ideas

Currently, time-based configurations require manual updates when daylight saving time (DST) changes. This feature request proposes an enhancement to enable the system to automatically adjust for DST without requiring manual modifications. Implementing this would ensure accurate time calculations, reduce the risk of errors, and eliminate the need for repeated adjustments.

Currently, admins who add secrets are not able to see the value of the secret they're adding. In cases where they use this secret and get an unauthorized error, it would be helpful to see the text they are entering to ensure it is 100% correct.

Hi, We have SSO integrations with two getport organizations (development, production). Each organization can be access via URLs like below. org-dev: https://auth.getport.io/authorize?response_type=token&client_id=XXXXXXX&connection=org-dev&redirect_uri=https%3A%2F%2Fapp.getport.io org-prod: https://auth.getport.io/authorize?response_type=token&client_id=XXXXXXXX&connection=org-prod&redirect_uri=https%3A%2F%2Fapp.getport.io The potential feature could be to have friendly URLs, for example: https://auth.getport.io/org_dev https://auth.getport.io/org_prod Or accessing it via custom DNS: https://my-custom-dns/org_dev https://my-custom-dns/org_prod

Allow customers to configure and manage SSO directly in Port UI without requiring support or customer success assistance. Proposed Solution: Introduce a self-service SSO feature that enables Port administrators to configure and manage SSO directly in Port UI without requiring support or customer success assistance. This feature should include native support for major providers like AzureAD and Okta, ability to test it before enforcing, and ability to apply additional provisioning like SCIM.

Today a user that is automatically created using integrations / API is disabled by default, and the only way to activate it is by doing that for every user using the UI / API, and if a disabled user tries to login using SSO the user is blocked from access. Ideally, we would want the first SSO login to activate the user, without sending an invitation

In order to prevent damage in an event of a leakage of an API key, extra security measures are needed. By whitelisting specific IP addresses for a Port organization, you reduce the impact of a leakage of API keys for an organization. Adding whitelisting in an organization level, and in an API key level will help protect customers' data.

OpenAPI specifications make it really easy for developers to start using API endpoints. If Port were to publish such a specification for their own APIs, this would make it much easier to quickly spin up adhoc requests for experimentation.

In order to improve adoption, key point is around branding, being able to use port ( even saas ) via a custom domain like port.mydomain.com , or dev-portal.mydomain.com can help tremendously on internal adoption

When I go to "credentials" tab I see secrets values, it may be a critical point when I work this and share my screen. I would be nice to hide the Client secret value by default (both Organization and Personal), make it blurred or something

Today when you type in a field related to sensitive inputs (for example, a new secret used for Port hosted integration), the characters in the field are shown as dots to mask the actual value. It would be very helpful to have a "reveal" button that will show the actual value after typing, it could help prevent typos or input mistakes