is it possible to manually verify existing users e...
# ory-network
b
is it possible to manually verify existing users email address via the http api / cli? Tried to do a patch (https://www.ory.sh/docs/kratos/reference/api#tag/identity/operation/patchIdentity) but that didn't do the trick 🙂
the request looks something like this:
Copy code
http PATCH <url>/admin/identities/$id Authorization:... --raw='[{"op": "replace", "path": "/verifiable_addresses/0/verified", "value": true}]'
I'm also able to set verified / not verified on some accounts (those that already are verified), but not those that are not
@magnificent-energy-493or anyone else in the ory team, you have any ideas? 😄 currently have a couple hundred users that are affected by this
a
I used the go client’s PatchIdentity method. The payload looks okay to me. I used the same path.
b
thanks for the reply Peter, good to know! Doesn't look like it's working for users that are not verified for me, if I do the patch the verified_addresses field just gets broken / all fields are set to its default null value
l
We do it via the Node SDK.
I think you may also need to include:
Copy code
{
    op: 'replace',
    path: `/verifiable_addresses/0/status`,
    value: 'completed'
}
b
now the request looks like this (using httpie)
Copy code
https PATCH "$URL/admin/identities/$id" Authorization:"Bearer $ORY_PAT"  --raw='[{"op": "replace", "path": "/verifiable_addresses/0/verified", "value": true}, {"op": "replace", "path": "/verifiable_addresses/0/status", "value": "completed"}]' --ignore-stdin
and getting response
Copy code
{
  ...
    "verifiable_addresses": [
        {
            "created_at": "0001-01-01T00:00:00Z",
            "id": "00000000-0000-0000-0000-000000000000",
            "status": "pending",
            "updated_at": "0001-01-01T00:00:00Z",
            "value": "<email...>",
            "verified": false,
            "via": "email"
        }
    ]
}
and before the request, the
verifiable_addresses
looks like
Copy code
"verifiable_addresses": [
        {
            "created_at": "2023-05-15T09:53:19.746119Z",
            "id": "e9b790d1-5a8a-47c3-9e89-631da586bcc8",
            "status": "pending",
            "updated_at": "2023-05-15T09:53:19.746119Z",
            "value": "<email...>",
            "verified": false,
            "via": "email"
        }
    ]
so it looks like the verifiable_addresses gets buggy after the patch
l
Do you have an API client you can try? I’ve done it that way as well:
b
does it work if the user is not verified initially? I am able to toggle verified if the user already is verified, but if they are not, it doesn't work
a
For me it works for un-verified users to verify them for the first time.
😶 1
l
Yes, I can verify and un-verify them.
👀 1
b
interesting. Doing the same as you guys (I believe), it breaks the verifiable addresses for me
Copy code
PATCH /admin/identities/80f862d8-5368-46ad-af35-2c6f14366d66 HTTP/1.1
Accept: application/json, */*;q=0.5
Accept-Encoding: gzip, deflate
Authorization: Bearer [redcated]
Connection: keep-alive
Content-Length: 161
Content-Type: application/json
Host: [redact].<http://projects.oryapis.com|projects.oryapis.com>
User-Agent: HTTPie/3.2.1

[
    {
        "op": "replace",
        "path": "/verifiable_addresses/0/verified",
        "value": true
    },
    {
        "op": "replace",
        "path": "/verifiable_addresses/0/status",
        "value": "completed"
    }
]


HTTP/1.1 200 OK
CF-Cache-Status: DYNAMIC
CF-RAY: 7c7bd349a9801bfe-OSL
Connection: keep-alive
Content-Encoding: gzip
Content-Type: application/json; charset=utf-8
Date: Mon, 15 May 2023 13:46:08 GMT
Server: cloudflare
Set-Cookie: __cflb=04dToYcAUjXzJV2aHSxAUzxjQ7PyYsiCEZygwZMECj; SameSite=None; Secure; path=/; expires=Mon, 15-May-23 14:46:08 GMT; HttpOnly
Transfer-Encoding: chunked
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
cache-control: private, no-cache, no-store, must-revalidate
ory-network-request-id: d735c903-861e-985f-9ceb-35de9d398928
vary: Origin

{
    "created_at": "2023-05-15T09:55:01.911017Z",
    "credentials": {
        "password": {
            "created_at": "2023-05-15T09:55:01.92815Z",
            "identifiers": [
                "<email>"
            ],
            "type": "password",
            "updated_at": "2023-05-15T11:11:20.285296Z",
            "version": 0
        },
        "webauthn": {
            "created_at": "2023-05-15T09:55:01.92815Z",
            "identifiers": [
                "<email>"
            ],
            "type": "webauthn",
            "updated_at": "2023-05-15T11:11:20.285296Z",
            "version": 1
        }
    },
    "id": "80f862d8-5368-46ad-af35-2c6f14366d66",
    "metadata_admin": {},
    "metadata_public": {
        ...
    },
    "recovery_addresses": [
        {
            "created_at": "0001-01-01T00:00:00Z",
            "id": "00000000-0000-0000-0000-000000000000",
            "updated_at": "0001-01-01T00:00:00Z",
            "value": "<email>",
            "via": "email"
        }
    ],
    "schema_id": "a477822909a87f5be801e919c2e07e4d650b065bee6e858f188a2c95781f087474748cf1d030e3d669c8456273786b8f021cab77f8c06dada0c2c675cf8b84be",
    "schema_url": "...",
    "state": "active",
    "state_changed_at": "2023-05-15T09:55:01.906426Z",
    "traits": {
        ...
    },
    "updated_at": "2023-05-15T09:55:01.911017Z",
    "verifiable_addresses": [
        {
            "created_at": "0001-01-01T00:00:00Z",
            "id": "00000000-0000-0000-0000-000000000000",
            "status": "pending",
            "updated_at": "0001-01-01T00:00:00Z",
            "value": "<email>",
            "verified": false,
            "via": "email"
        }
    ]
}
l
The only difference I see between your request and mine is that I do not have the
Copy code
Accept: application/json, */*;q=0.5
Accept-Encoding: gzip, deflate
request headers, and my
Content-Type
header is
Content-Type: application/json; charset=utf-8
.
a
I’m using Python to send the request. It sends
Copy code
'Accept-Encoding': 'gzip, deflate'
'Accept': '*/*'
'Content-Type': 'application/json'