📦 Pull Request

This pull implements an alternate ecRecover process internally as opposed to using digitaldonkey/ecverify. This is due to the reasons described in this issue. In summary this pull will allow this package to support runtimes that do not have the gmp extension installed as long as the bcmath extension is installed.

No new functionality has been introduced.

One thing to note is that although calls to $magic->token->validate() will work without gmp as long as bcmath is installed, there is a significant performance difference between the two. This is why the simplito/bigint-wrapper-php sub-dependency is designed to work with gmp first and bcmath as a fallback.

On average calls to $magic->token->validate() took about 17ms with gmp versus 320ms with bcmath. In apps where validate is being called on every request this may be a showstopper for some users.

Users should be encouraged to install gmp whenever possible, but also made aware that the package will work with bcmath as an alternative. Currently there are various hosting platforms that do not support gmp, like Laravel Vapor for example.

🗜 Versioning

(Check one!)

• [x] Patch: Bug Fix?
• [ ] Minor: New Feature?
• [ ] Major: Breaking Change?

📦 Pull Request

The current implementation of magic-admin-php for metadata retrieval returns the Ethereum public_address.

We are adding functionality to query wallet(s) for any chain tied to the end-user.

Example (queries all Solana wallets created for the user if applicable): $meta = $magic->user->get_metadata_by_token_and_wallet($did_token, \MagicAdmin\Resource\Wallet::SOLANA);

Example (queries all wallets created for the user if applicable): $meta = $magic->user->get_metadata_by_token_and_wallet($did_token, \MagicAdmin\Resource\Wallet::ANY);

Please see supported wallet types in lib/Resource/Wallet.php.

🗜 Versioning

(Check one!)

• [ ] Patch: Bug Fix?
• [x] Minor: New Feature?
• [ ] Major: Breaking Change?

✅ Fixed Issues

• [List any fixed issues here like: Fixes #XXXX]

🚨 Test instructions

./vendor/bin/phpunit tests  3.0.0 02:30:07 PM PHPUnit 8.5.31 by Sebastian Bergmann and contributors.

.................................................. 50 / 50 (100%)

Time: 74 ms, Memory: 8.00 MB

OK (50 tests, 83 assertions)

⚠️ Update CHANGELOG.md

• [x] I have updated the Upcoming Changes section of CHANGELOG.md with context related to this Pull Request.

📦 Pull Request

Release v0.1.3

🗜 Versioning

(Check one!)

None

✅ Fixed Issues

None

🚨 Test instructions

[Describe any additional context required to test the PR/feature/bug fix.]

⚠️ Update CHANGELOG.md

• [X] I have updated the Upcoming Changes section of CHANGELOG.md with context related to this Pull Request.

📦 Pull Request

Release v0.1.2

🗜 Versioning

(Check one!)

None

✅ Fixed Issues

None

🚨 Test instructions

[Describe any additional context required to test the PR/feature/bug fix.]

⚠️ Update CHANGELOG.md

• [x] I have updated the Upcoming Changes section of CHANGELOG.md with context related to this Pull Request.

📦 Pull Request

Use isset to check if a key exists in the claim array to support PHP7.4

🗜 Versioning

(Check one!)

• [x] Patch: Bug Fix?
• [ ] Minor: New Feature?
• [ ] Major: Breaking Change?

✅ Fixed Issues

• Fixes https://github.com/magiclabs/magic-admin-php/issues/6

🚨 Test instructions

• Tests passed
• Manually verified with PHP7.4

⚠️ Update CHANGELOG.md

• [x] I have updated the Upcoming Changes section of CHANGELOG.md with context related to this Pull Request.

✅ Prerequisites

• [X] Did you perform a cursory search of open issues? Is this bug already reported elsewhere?
• [X] Are you running the latest SDK version?
• [x] Are you reporting to the correct repository (magic-admin-php)?

🐛 Description

/lib/Resource/Token.php:26 throws an exception in PHP 7.4:

ErrorException: array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead

Using array_key_exists() on objects is deprecated in PHP 7.4.

🧩 Steps to Reproduce

1. composer require magiclabs/magic-admin-php
2. (Get $did_token from client)
3. $magic = new \MagicAdmin\Magic(env('MAGIC_SECRET'));
4. $magic->token->validate($did_token); or $issuer = $magic->token->get_issuer($did_token);

🤔 Expected behavior

Validate or get issuer from the DID token

😮 Actual behavior

ErrorException: array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead

/.../vendor/magiclabs/magic-admin-php/lib/Resource/Token.php:26
/.../vendor/magiclabs/magic-admin-php/lib/Resource/Token.php:66
/.../vendor/magiclabs/magic-admin-php/lib/Resource/Token.php:73

💻 Code Sample

$magic = new \MagicAdmin\Magic(env('MAGIC_SECRET_KEY'));
try {
    $magic->token->validate($did_token);
    $issuer = $magic->token->get_issuer($did_token);
} catch (\MagicAdmin\Exception\DIDTokenException $e) {
    dd($e->getErrorMessage());
}

🌎 Environment

| Software | Version(s) | | ------------------- | ---------- | | magic-admin-php | 0.1.0 | | php | 7.4.12 | | Operating System | macOS 10.15.7 |

📦 Pull Request

An attempt to fix composer autoload issue

🗜 Versioning

(Check one!)

• [x] Patch: Bug Fix?
• [ ] Minor: New Feature?
• [ ] Major: Breaking Change?

✅ Fixed Issues

• N/A

🚨 Test instructions

Minimal

⚠️ Update CHANGELOG.md

• pre-release

✅ Prerequisites

• [x] Did you perform a cursory search of open issues? Is this feature already requested elsewhere?
• [x] Are you reporting to the correct repository (magic-admin-php)?

✨ Feature Request

Hi, could you include more data to /v1/admin/auth/user/get and let end users (us) decide which specific piece of data should be made useful. From the perspective of single-responsibility principle, it makes sense that provenance, signup_ts and more belong to user meta data. Also adding them wouldn't break any existing functionalities.

Or you already have APIs available for more user data?

🧩 Context

This feature request is to accommodate the inability of linking email and social logins on your platform. In our system, we'd like to direct all logins with the same email address to one account. We've managed to associate link login and social logins to one account on our end, but there is a security issue in which it is possible to generate a Magic token from social login and use the token to access the API for link login. We need to check provenance to make sure users do not abuse our APIs.

Another way is to make use of the add field in a DID token, which is not available to us neither https://magic.link/docs/introduction/decentralized-id#decentralized-id-token-specification

A hard way is to maintain a table on our own and sync with https://api.magic.link/v2/dashboard/magic_client/users?magic_client_id=[MAGIC_CLIENT_ID]=&limit=10&offset=50&include_count=1 which gives us provenance. It's impossible to happen due to the complexity, it would also double the time spent on login.

       {
                "id": [EMAIL_ADDR]',
                "magic_client_id": [CLIENT_ID],
                "provenance": "LINK",
                "signup_ts": 1625162812
        },
        {
                "id": [EMAIL_ADDR]',
                "magic_client_id": [CLIENT_ID],
                "provenance": "apple",
                "signup_ts": 1625162812
        },

💻 Examples

{
    "data": {
        "email": [EMAIL],
        "issuer": [ISSUER],
        "public_address": [PUBLIC_ADDRESS],
        "provenance": [PROVENANCE],
        ...
    },
    ...
}