Allow external access to specific user in MariaDB 10.3 - mariadb

Question

I'm trying to configure a limited external access to MariaDB 10.3
What I want
The user can only access to a view from an external access but shouldn't be able to be connected as root even if he has the password.
Initial configuration
Using the default forge configuration we start with theses users:
$ mysql -u root -p
> use information_schema;
> select * from user_privileges;
Full result: https://pastebin.com/kNNVUjrz
TLDR;
Two root users:
root accessible from : [localhost, 127.0.0.1, ::1, 51.99.999.101*, %]
forge accessible from : [51.99.999.101*, %]
One weird user:
debian-sys-maint accessible from : [localhost]
.* This is obviously a fake public ip
Configuration I want
root accessible from : [localhost, 127.0.0.1, ::1, 51.99.999.101]
forge accessible from : [localhost, 127.0.0.1, ::1, 51.99.999.101]
dummyuser accessible form : [%]
The problem
When I remove the user 'forge'#'%' but keep 'forge'#'localhost', the user (dummyuser) has no more privileges.
ERROR 1045 (28000): Access denied for user 'dummyuser'#'%' (using password: YES)
Details of what I did
connected through SSH to the server
$ mysql -u forge -p
> create database mydb;
> create view mydb.v as select user();
> create user dummyuser identified by 'password';
> grant select on mydb.v to dummyuser;
> select * from information_schema.user_privileges where grantee like '%dummyuser%';
GRANTEE: 'dummyuser'#'%'
TABLE_CATALOG: def
PRIVILEGE_TYPE: USAGE
IS_GRANTABLE: NO
Connected through my local PC
$ mysql -u dummyuser -h 51.99.999.101 -p
> select * from mydb.v;
Returns what we want: dummyuser#adsl-178-xx-xxx-123.adslplus.ch
But now when I delete the user 'forge'#'%' through SSH (with root this time):
Important Note: Doing this step before creating the dummyuser did not solve the problem.
$ mysql -u root -p
> drop user 'forge'#'%';
> create user 'forge'#'localhost' identified by 'passowrd';
> grant all privileges on *.* to 'forge'#'localhost' with grant option;
> flush privileges;
Here come the problem: When I logon with dummyuser and try again:
$ mysql -u dummyuser -h 51.99.999.101 -p
> select * from mydb.v;
ERROR 1045 (28000): Access denied for user 'dummyuser'#'%' (using password: YES)

Answer 1

Start by finding out what rows exist in the grant tables. It looks like you may have done such, but let's do it two steps:
SELECT user, host FROM mysql.user;
Then, for each of those, do (with ... appropriately filled in):
SHOW GRANTS FOR '...'#'...'
Now take the GRANT ... TO ... statements that that produced, turn them into REVOKE ... FROM ... (and remove the password clause).
Run those REVOKEs plus any new GRANTs you need. But be sure that a typo does not lock you out. Stay connected while you connect elsewhere and check the results.

Answer 2

With the help of #rick-james I got a working case.
I had to (re)create a user 'forge'#'%' with the same restricted access than 'dummyuser'#'%'.
'forge'#'localhost' keep is privileges root
> show grants for root#localhost;
GRANT ALL PRIVILEGES ON *.* TO 'root'#'localhost' IDENTIFIED BY PASSWORD '*****' WITH GRANT OPTION
GRANT PROXY ON ''#'%' TO 'root'#'localhost' WITH GRANT OPTION
> show grants for forge#localhost;
GRANT ALL PRIVILEGES ON *.* TO 'forge'#'localhost' IDENTIFIED BY PASSWORD '*****' WITH GRANT OPTION
> show grants for 'forge'#'%';
GRANT USAGE ON *.* TO 'forge'#'%' IDENTIFIED BY PASSWORD '*****'
GRANT SELECT ON `mydb`.`v` TO 'forge'#'%'
> show grants for 'dummyuser'#'%';
GRANT USAGE ON *.* TO 'dummyuser'#'%' IDENTIFIED BY PASSWORD '*****'
GRANT SELECT ON `mydb`.`v` TO 'dummyuser'#'%'
Now when I create dummyuser3#% with the user forge#localhost and grant him: grant select on mydb.v to dummyuser3; the dummyuser3 will be able to select the view.
In case a user get access to forge#%, because of the restriction, it will only be able to select the view. Which is an acceptable solution.
[Edit] It works with THIS scenario: create view mydb.v as select user();
In a real world, my view is based on an another table. In that case, the user 'forge'#'%' also needs the privilege to select on that table.
This is a less acceptable solution. But that's the only one I got.
In definitive, the question is still open