Is restricted (client) access possible

[srdco]

I was exploring the possibility of using this as a portal for customers ...

1. Is there a way to restrict client access to only matters that they are assigned to? For example, Joe Client is assigned by Pete Practitioner to application GreatIdea1. When Joe Client signs in, he can ONLY see GreatIdea1 (and any other applications he has been assigned to).
2. Also (and this would be optional but highly desirable) would there be a way to give them read-only access? (i.e. don't let them inadvertently disrupt dates and information ... inventors tend to be very hands-on people and many would likely assume it is OK to explore functionality)

[jjdejong]

Absolutely. We offer that to our clients. The clients only see their data and do not have access to the edition controls and tables.

For the actor you set as a "Client" in your matters:

• Set "Default Role" to "Client"
• Set the login and email fields
• Communicate the login to your client and tell him to go to the login screen and select "Forgot password" - he will get a link via email to (re)set his password (provided you configured your email system in the .env file).

Note that the edition resources are only hidden in the UI - if he guesses the URLs, he can use them. For true read-only access, you need to create a read-only DB user, say "phpip_ro", and assign that to DB_USERNAME in your client's .env file instead of "phpip". (You can override the .env file settings by setting the variables in your virtual host configuration with the SetEnv DB_USERNAME phpip_ro directive - you probably want a different virtual host for your client pointing to the same instance.)

The phpip_ro user needs the following grants:

GRANT SELECT ON `phpip`.* TO 'phpip_ro'@'localhost'
GRANT UPDATE (remember_token, last_login) ON `phpip`.`actor` TO 'phpip_ro'@'localhost'
GRANT INSERT, UPDATE, DELETE, REFERENCES ON `phpip`.`password_resets` TO 'phpip_ro'@'localhost'

[srdco]

BRILLIANT!
It worked. The main detail on the PHPIP side that I was missing was to set the Default Role as "Client." (I hadn't bothered to even set the default role on my test client user).

I also followed your suggestion and created a new read-only database user and a Virtual Host (I set it up to access from 2 different subdomains depending on whether you are a client or staff). I removed three parameters from the .env: DB_USERNAME, DB_PASSWORD, and APP_URL, and set them to be passed dynamically in the virtual host configuration, so now the last section of the NGINX configuration files (one for client access and one for staff access) in #8 is now:

    location ~ \.php {
        fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param DB_USERNAME "your-database-username";
        fastcgi_param DB_PASSWORD "your-database-password";
        fastcgi_param APP_URL "https://your-domain.com";
        include fastcgi_params;
    }

Note: I know you indicated you can just dynamically override the parameters; however, I wanted a failsafe: I would rather access error out than accidentally have the wrong access level. Of course, I suppose you could just put client access in as the default in the .env file...

One other note: The Client access level has an amazing dashboard ... but the Client can still click on an individual matter, and then Delete or Update the matter (the buttons are still visible) -- which could be catastrophic. By making sure that the client accesses it using a read-only database user, the danger is bypassed.

One final note: Hypothetically, if a Client knew the URL that the staff used (e.g. staffaccess.phpip.com vs clientaccess.phpip.com), then they could login and still update or delete matters. I can see that COULD happen inadvertently (attorney copy-pastes their access and emails it to client instead of sending client access url ...).
I wonder if there is a straightforward way to set it up so that when a client logs in, it checks to make sure that they are using the right .env configuration, and throws an error if not? Not super familiar with Laravel, so not sure...

At any rate, THANK YOU! This package is extremely helpful, and I appreciate the contribution to the IP community.

[jjdejong]

One other note: The Client access level has an amazing dashboard ... but the Client can still click on an individual matter, and then Delete or Update the matter (the buttons are still visible) -- which could be catastrophic. By making sure that the client accesses it using a read-only database user, the danger is bypassed.

That is preferable, especially because the client could guess the CRUD resources for making updates and deletions.

One final note: Hypothetically, if a Client knew the URL that the staff used (e.g. staffaccess.phpip.com vs clientaccess.phpip.com), then they could login and still update or delete matters. I can see that COULD happen inadvertently (attorney copy-pastes their access and emails it to client instead of sending client access url ...).

Good point. The latest commit now hides all edition controls to the client (but they could still guess the CRUD resources...).

I wonder if there is a straightforward way to set it up so that when a client logs in, it checks to make sure that they are using the right .env configuration, and throws an error if not? Not super familiar with Laravel, so not sure...

The current implementation is a quick and dirty one. I do envision fine-tuning permissions, be it for authorizing different access levels to the staff (admin, read/write, read-only). This can be done cleanly via the Authorization services in Laravel (of which I've scratched the possibilities for the clients).