Concern about verification_url.

[LiamKarlMitchell]

If the verification_url is sent during register (or resend email mutation) by a malicious user, couldn't they trick a user / admin into entering their login into a different website which may appear to look like real one?

Wouldn't it be better to have a server side generated url, or at least a way to verify and limit the input accordingly (so that app based urls or custom schemes could potentially be used) although I can't see how to generate 1 url for Desktop browser and 1 for a mobile (android/iOS).

Leaving the verification_url blank however is seeming to generate the url in a different way and not have a valid signature when submitting the Verify Email mutation with the details extracted from the link in the email received so that it does not let me validate with the mutation and signed url enabled in the config.

I think that a validation rule of some kind could be added to the graphql mutations schema for Register and Resend Verification mutations to mitigate this where the url value is confirmed to

1. Be set.
2. Match specific pattern/protocol/domain/path and have only the expected query params.

Lets say "some_pish_website.com" looks the part and is very similar to "real-domain.com" but the user or admin is perhaps not so technically adept to recognize this threat. They see an email that for all accounts uses the same email template and comes from the same sender as legitimate emails from the service they do recognize so they trust it and do not realize the problem.

mutation register($input: RegisterInput!) {
  register (input: $input) {
    status
    token
  }
}

{
  "input": {
    "name" :"Bob Admin",
    "email": "[email protected]",
    "password": "password1234",
    "password_confirmation": "password1234",
    "verification_url": {
        "url": "https://some_pish_website.com/verify-email/__ID__/__HASH__/?expires=__EXPIRES__&signature=__SIGNATURE__"
    }
  }
}