magiclabs/magic-admin-php

Magic admin PHP SDK makes it easy to leverage Decentralized ID tokens to protect routes and restricted resources for your application.

magic-admin-php's Issues

Exception: Using array_key_exists() on objects is deprecated in PHP 7.4

✅ Prerequisites

• Did you perform a cursory search of open issues? Is this bug already reported elsewhere?
• Are you running the latest SDK version?
• 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

Include provenance and more to user meta data

✅ Prerequisites

• Did you perform a cursory search of open issues? Is this feature already requested elsewhere?
• 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],
        ...
    },
    ...
}

PHP LOGIN support

✅ Prerequisites

• Did you perform a cursory search of open issues? Is this question already asked elsewhere?
• Are you reporting to the correct repository (magic-admin-php)?

❓ Question

So, is there a way to actually LOG the user into via a request from the frontend? If the user is only logging in via the CLIENT side, then any information generated by that login wouldn't be trusted on the BACKEND - even if you hooked into the 'ready' state - as if you have to send a request to the backend to CHECK if the user is logged in, then, that can be spoofed by even a 3rd grader.

Normally, I'd expect the process to work like:

• user is on login page
• user enters email
• user clicks login
• ajax request sends email to backend
• backend generates a unique signing code/link to give to the user
• system redirects user to that link
• user logs in
• webhook triggers proving user logged in by passing the needed information (email and did) back to the server side without any user or client side interactions
• frontend waits for confirmation that the user has successfully logged in (simple polling can do this)
• once confirmed in db that they are logged in, takes the user to the homepage of the app

However, it doesn't appear that magic supports any webhooks for PHP or true server side applications.

So, how can one actually IMPLEMENT this if their application is PHP based (and not laravel/symfony based), as nothing that is sent from the CLIENT side can be trusted?

🌎 Environment

Software	Version(s)
magic-admin-php	latest
php	8.1
Operating System	ubuntu 20.04