# Which Problems Are Solved
The service name is hardcoded in the metrics code. Making the service
name to be configurable helps when running multiple instances of
Zitadel.
The defaults remain unchanged, the service name will be defaulted to
ZITADEL.
# How the Problems Are Solved
Add a config option to override the name in defaults.yaml and pass it
down to the corresponding metrics or tracing module (google or otel)
# Additional Changes
NA
# Additional Context
NA
(cherry picked from commit dc64e35128)
# Which Problems Are Solved
The service name is hardcoded in the metrics code. Making the service
name to be configurable helps when running multiple instances of
Zitadel.
The defaults remain unchanged, the service name will be defaulted to
ZITADEL.
# How the Problems Are Solved
Add a config option to override the name in defaults.yaml and pass it
down to the corresponding metrics or tracing module (google or otel)
# Additional Changes
NA
# Additional Context
NA
# Which Problems Are Solved
Zitadel should not record 404 response counts of unknown paths (check
`/debug/metrics`).
This can lead to high cardinality on metrics endpoint and in traces.
```
GOOD http_server_return_code_counter_total{method="GET",otel_scope_name="",otel_scope_version="",return_code="200",uri="/.well-known/openid-configuration"} 2
GOOD http_server_return_code_counter_total{method="GET",otel_scope_name="",otel_scope_version="",return_code="200",uri="/oauth/v2/keys"} 2
BAD http_server_return_code_counter_total{method="GET",otel_scope_name="",otel_scope_version="",return_code="404",uri="/junk"} 2000
```
After
```
GOOD http_server_return_code_counter_total{method="GET",otel_scope_name="",otel_scope_version="",return_code="200",uri="/.well-known/openid-configuration"} 2
GOOD http_server_return_code_counter_total{method="GET",otel_scope_name="",otel_scope_version="",return_code="200",uri="/oauth/v2/keys"} 2
```
# How the Problems Are Solved
This PR makes sure, that any unknown path is recorded as `UNKNOWN_PATH`
instead of the actual path.
# Additional Changes
N/A
# Additional Context
On our production instance, when a penetration test was run, it caused
our metric count to blow up to many thousands due to Zitadel recording
404 response counts.
Next nice to have steps, remove 404 timer recordings which serve no
purpose
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
Co-authored-by: Silvan <27845747+adlerhurst@users.noreply.github.com>
Co-authored-by: Livio Spring <livio@zitadel.com>
(cherry picked from commit 599850e7e8)
# Which Problems Are Solved
Zitadel should not record 404 response counts of unknown paths (check
`/debug/metrics`).
This can lead to high cardinality on metrics endpoint and in traces.
```
GOOD http_server_return_code_counter_total{method="GET",otel_scope_name="",otel_scope_version="",return_code="200",uri="/.well-known/openid-configuration"} 2
GOOD http_server_return_code_counter_total{method="GET",otel_scope_name="",otel_scope_version="",return_code="200",uri="/oauth/v2/keys"} 2
BAD http_server_return_code_counter_total{method="GET",otel_scope_name="",otel_scope_version="",return_code="404",uri="/junk"} 2000
```
After
```
GOOD http_server_return_code_counter_total{method="GET",otel_scope_name="",otel_scope_version="",return_code="200",uri="/.well-known/openid-configuration"} 2
GOOD http_server_return_code_counter_total{method="GET",otel_scope_name="",otel_scope_version="",return_code="200",uri="/oauth/v2/keys"} 2
```
# How the Problems Are Solved
This PR makes sure, that any unknown path is recorded as `UNKNOWN_PATH`
instead of the actual path.
# Additional Changes
N/A
# Additional Context
On our production instance, when a penetration test was run, it caused
our metric count to blow up to many thousands due to Zitadel recording
404 response counts.
Next nice to have steps, remove 404 timer recordings which serve no
purpose
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
Co-authored-by: Silvan <27845747+adlerhurst@users.noreply.github.com>
Co-authored-by: Livio Spring <livio@zitadel.com>
# Which Problems Are Solved
Added search by phone to user Service V2.
```
curl --request POST \
--url https://<zitadel_domain>/v2/users \
--header 'Accept: application/json' \
--header 'Authorization: Bearer <Token>' \
--header 'Content-Type: application/json' \
--header 'content-type: application/json' \
--data '{
"query": {
"offset": "0",
"limit": 100,
"asc": true
},
"sortingColumn": "USER_FIELD_NAME_UNSPECIFIED",
"queries": [
{
"phoneQuery": {
"number": "+12011223313",
"method": "TEXT_QUERY_METHOD_EQUALS"
}
}
]
}'
```
Why?
Searching for a user by phone was missing from User Service V2 and V2
beta.
# How the Problems Are Solved
* Added to the SearchQuery proto
* Added code to filter users by phone
# Additional Changes
N/A
# Additional Context
Search by phone is present in V3 User Service
---------
Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
# Which Problems Are Solved
The success and failure URLs post IDP intent are limited to 200
characters. This is very low given the standard for URL lengths is much
higher
https://www.baeldung.com/cs/max-url-length#maximum-length-of-a-url-in-different-browsers
Name of the Browser | URL Length
-- | --
Google Chrome | Maximum of 2048 characters for a URL
Mozilla Firefox | The address bar no longer shows the URL after 65536
characters
Internet Explorer | Maximum length of the URL is 2083 characters
Safari | Supports up to 80000 characters for a URL
Opera | Can display up to 190000 characters in its address bar
Apache | Supports a maximum of 4000 characters
The user post SSO login w/ Zitadel, sees deep links to out app e.g.
`www.mycompany.com/idp/success?deeplink=app/mypage/id/test#thing=abcdef`
and these are usually greater than 200 characters.
# How the Problems Are Solved
Replace this example text with a concise list of changes that this PR
introduces.
- Update validation check for SuccessURL length on v2 and v3 APIs to a
max of 2048 characters
- Update validation check for FailureURL length on v2 and v3 APIs to a
max of 2048 characters
I didn't find any docs t update reflecting this change in length
# Additional Context
Fixes the error
```<PreparedRequest [POST]>, status: 400, reason: Bad Request, response: {"code":3,"message":"invalid StartIdentityProviderIntentRequest.Urls: embedded message failed validation | caused by: invalid RedirectURLs.SuccessUrl: value length must be between 1 and 200 runes, inclusive"}```
(cherry picked from commit d90db6693c)
# Which Problems Are Solved
The success and failure URLs post IDP intent are limited to 200
characters. This is very low given the standard for URL lengths is much
higher
https://www.baeldung.com/cs/max-url-length#maximum-length-of-a-url-in-different-browsers
Name of the Browser | URL Length
-- | --
Google Chrome | Maximum of 2048 characters for a URL
Mozilla Firefox | The address bar no longer shows the URL after 65536
characters
Internet Explorer | Maximum length of the URL is 2083 characters
Safari | Supports up to 80000 characters for a URL
Opera | Can display up to 190000 characters in its address bar
Apache | Supports a maximum of 4000 characters
The user post SSO login w/ Zitadel, sees deep links to out app e.g.
`www.mycompany.com/idp/success?deeplink=app/mypage/id/test#thing=abcdef`
and these are usually greater than 200 characters.
# How the Problems Are Solved
Replace this example text with a concise list of changes that this PR
introduces.
- Update validation check for SuccessURL length on v2 and v3 APIs to a
max of 2048 characters
- Update validation check for FailureURL length on v2 and v3 APIs to a
max of 2048 characters
I didn't find any docs t update reflecting this change in length
# Additional Context
Fixes the error
```<PreparedRequest [POST]>, status: 400, reason: Bad Request, response: {"code":3,"message":"invalid StartIdentityProviderIntentRequest.Urls: embedded message failed validation | caused by: invalid RedirectURLs.SuccessUrl: value length must be between 1 and 200 runes, inclusive"}```
Harsha Reddy
