| 1 | /****************************************************************************** |
| 2 | * THIS FILE IS GENERATED - ANY EDITS WILL BE OVERWRITTEN |
| 3 | */ |
| 4 | |
| 5 | #pragma once |
| 6 | |
| 7 | #include <Quotient/csapi/definitions/user_identifier.h> |
| 8 | #include <Quotient/csapi/definitions/wellknown/full.h> |
| 9 | |
| 10 | #include <Quotient/jobs/basejob.h> |
| 11 | |
| 12 | namespace Quotient { |
| 13 | |
| 14 | /*! \brief Get the supported login types to authenticate users |
| 15 | * |
| 16 | * Gets the homeserver's supported login types to authenticate users. Clients |
| 17 | * should pick one of these and supply it as the `type` when logging in. |
| 18 | */ |
| 19 | class QUOTIENT_API GetLoginFlowsJob : public BaseJob { |
| 20 | public: |
| 21 | // Inner data structures |
| 22 | |
| 23 | /// Gets the homeserver's supported login types to authenticate users. |
| 24 | /// Clients should pick one of these and supply it as the `type` when |
| 25 | /// logging in. |
| 26 | struct LoginFlow { |
| 27 | /// The login type. This is supplied as the `type` when |
| 28 | /// logging in. |
| 29 | QString type; |
| 30 | /// If `type` is `m.login.token`, an optional field to indicate |
| 31 | /// to the unauthenticated client that the homeserver supports |
| 32 | /// the [`POST |
| 33 | /// /login/get_token`](/client-server-api/#post_matrixclientv1loginget_token) |
| 34 | /// endpoint. Note that supporting the endpoint does not |
| 35 | /// necessarily indicate that the user attempting to log in will |
| 36 | /// be able to generate such a token. |
| 37 | bool getLoginToken{ false }; |
| 38 | }; |
| 39 | |
| 40 | // Construction/destruction |
| 41 | |
| 42 | /// Get the supported login types to authenticate users |
| 43 | explicit GetLoginFlowsJob(); |
| 44 | |
| 45 | /*! \brief Construct a URL without creating a full-fledged job object |
| 46 | * |
| 47 | * This function can be used when a URL for GetLoginFlowsJob |
| 48 | * is necessary but the job itself isn't. |
| 49 | */ |
| 50 | static QUrl makeRequestUrl(QUrl baseUrl); |
| 51 | |
| 52 | // Result properties |
| 53 | |
| 54 | /// The homeserver's supported login types |
| 55 | QVector<LoginFlow> flows() const |
| 56 | { |
| 57 | return loadFromJson<QVector<LoginFlow>>(keyName: "flows"_ls ); |
| 58 | } |
| 59 | }; |
| 60 | |
| 61 | template <> |
| 62 | struct JsonObjectConverter<GetLoginFlowsJob::LoginFlow> { |
| 63 | static void fillFrom(const QJsonObject& jo, |
| 64 | GetLoginFlowsJob::LoginFlow& result) |
| 65 | { |
| 66 | fillFromJson(jv: jo.value(key: "type"_ls ), pod&: result.type); |
| 67 | fillFromJson(jv: jo.value(key: "get_login_token"_ls ), pod&: result.getLoginToken); |
| 68 | } |
| 69 | }; |
| 70 | |
| 71 | /*! \brief Authenticates the user. |
| 72 | * |
| 73 | * Authenticates the user, and issues an access token they can |
| 74 | * use to authorize themself in subsequent requests. |
| 75 | * |
| 76 | * If the client does not supply a `device_id`, the server must |
| 77 | * auto-generate one. |
| 78 | * |
| 79 | * The returned access token must be associated with the `device_id` |
| 80 | * supplied by the client or generated by the server. The server may |
| 81 | * invalidate any access token previously associated with that device. See |
| 82 | * [Relationship between access tokens and |
| 83 | * devices](/client-server-api/#relationship-between-access-tokens-and-devices). |
| 84 | */ |
| 85 | class QUOTIENT_API LoginJob : public BaseJob { |
| 86 | public: |
| 87 | /*! \brief Authenticates the user. |
| 88 | * |
| 89 | * \param type |
| 90 | * The login type being used. |
| 91 | * |
| 92 | * \param identifier |
| 93 | * Authenticates the user, and issues an access token they can |
| 94 | * use to authorize themself in subsequent requests. |
| 95 | * |
| 96 | * If the client does not supply a `device_id`, the server must |
| 97 | * auto-generate one. |
| 98 | * |
| 99 | * The returned access token must be associated with the `device_id` |
| 100 | * supplied by the client or generated by the server. The server may |
| 101 | * invalidate any access token previously associated with that device. See |
| 102 | * [Relationship between access tokens and |
| 103 | * devices](/client-server-api/#relationship-between-access-tokens-and-devices). |
| 104 | * |
| 105 | * \param password |
| 106 | * Required when `type` is `m.login.password`. The user's |
| 107 | * password. |
| 108 | * |
| 109 | * \param token |
| 110 | * Required when `type` is `m.login.token`. Part of Token-based login. |
| 111 | * |
| 112 | * \param deviceId |
| 113 | * ID of the client device. If this does not correspond to a |
| 114 | * known client device, a new device will be created. The given |
| 115 | * device ID must not be the same as a |
| 116 | * [cross-signing](/client-server-api/#cross-signing) key ID. |
| 117 | * The server will auto-generate a device_id |
| 118 | * if this is not specified. |
| 119 | * |
| 120 | * \param initialDeviceDisplayName |
| 121 | * A display name to assign to the newly-created device. Ignored |
| 122 | * if `device_id` corresponds to a known device. |
| 123 | * |
| 124 | * \param refreshToken |
| 125 | * If true, the client supports refresh tokens. |
| 126 | */ |
| 127 | explicit LoginJob(const QString& type, |
| 128 | const Omittable<UserIdentifier>& identifier = none, |
| 129 | const QString& password = {}, const QString& token = {}, |
| 130 | const QString& deviceId = {}, |
| 131 | const QString& initialDeviceDisplayName = {}, |
| 132 | Omittable<bool> refreshToken = none); |
| 133 | |
| 134 | // Result properties |
| 135 | |
| 136 | /// The fully-qualified Matrix ID for the account. |
| 137 | QString userId() const { return loadFromJson<QString>(keyName: "user_id"_ls ); } |
| 138 | |
| 139 | /// An access token for the account. |
| 140 | /// This access token can then be used to authorize other requests. |
| 141 | QString accessToken() const |
| 142 | { |
| 143 | return loadFromJson<QString>(keyName: "access_token"_ls ); |
| 144 | } |
| 145 | |
| 146 | /// A refresh token for the account. This token can be used to |
| 147 | /// obtain a new access token when it expires by calling the |
| 148 | /// `/refresh` endpoint. |
| 149 | QString refreshToken() const |
| 150 | { |
| 151 | return loadFromJson<QString>(keyName: "refresh_token"_ls ); |
| 152 | } |
| 153 | |
| 154 | /// The lifetime of the access token, in milliseconds. Once |
| 155 | /// the access token has expired a new access token can be |
| 156 | /// obtained by using the provided refresh token. If no |
| 157 | /// refresh token is provided, the client will need to re-log in |
| 158 | /// to obtain a new access token. If not given, the client can |
| 159 | /// assume that the access token will not expire. |
| 160 | Omittable<int> expiresInMs() const |
| 161 | { |
| 162 | return loadFromJson<Omittable<int>>(keyName: "expires_in_ms"_ls ); |
| 163 | } |
| 164 | |
| 165 | /// ID of the logged-in device. Will be the same as the |
| 166 | /// corresponding parameter in the request, if one was specified. |
| 167 | QString deviceId() const { return loadFromJson<QString>(keyName: "device_id"_ls ); } |
| 168 | |
| 169 | /// Optional client configuration provided by the server. If present, |
| 170 | /// clients SHOULD use the provided object to reconfigure themselves, |
| 171 | /// optionally validating the URLs within. This object takes the same |
| 172 | /// form as the one returned from .well-known autodiscovery. |
| 173 | Omittable<DiscoveryInformation> wellKnown() const |
| 174 | { |
| 175 | return loadFromJson<Omittable<DiscoveryInformation>>(keyName: "well_known"_ls ); |
| 176 | } |
| 177 | }; |
| 178 | |
| 179 | } // namespace Quotient |
| 180 | |