• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Login to client account programatically

#11
Does a client always login via the main domain, or can they also login via the subdomain?
Reply

#12
The client only logs in via the subdomain.

There is a "super admin" area on the main domain for me, from which I want to be able to "login as" the user into their subdomain account.
Reply

#13
If only you as the super admin can access all accounts, why not just add an area on the main domain where you can view the info you want to view?

You say that the subdomain is used to connect to the correct database. So i'm guessing the main database has a list of all the known subdomains. You can create a library that uses it's own DB connection to communicate with the clients DB

Or

You could just add your admin user credentials to the clients user table. But that will still require a double log in
Reply

#14
(05-12-2017, 12:14 AM)Martin7483 Wrote: If only you as the super admin can access all accounts, why not just add an area on the main domain where you can view the info you want to view?

It's not about just accessing info, as it is a full CMS-type setup, so there would be too much info to simply list.

(05-12-2017, 12:14 AM)Martin7483 Wrote: You say that the subdomain is used to connect to the correct database. So i'm guessing the main database has a list of all the known subdomains. You can create a library that uses it's own DB connection to communicate with the clients DB

Or

You could just add your admin user credentials to the clients user table. But that will still require a double log in

Yes, the main DB has a list of all accounts/subdomains. There's no problem with me being able to connect to the client DB, but I would prefer to be able to access their account as they would, and see what they see (for management and troubleshooting), hence why I thought it'd be easiest to just log in as them (there is also specific info each user will see, so best to see the system through their login when debugging).

So do you think my initial idea is not possible? No way to set the cookie domain or otherwise recreate the login as that user, from a different domain?
Reply

#15
Which session driver are you using?
And in which DB are the user credentials stored?
Reply

#16
Using files session driver. Client DB has the user credentials for that subdomain. Master DB has my super admin user login.
Reply

#17
Then I would extend the method you use that checks from which domain a request is coming.

Set CI up that test.example.com === example.com/test.example.com when you have a valid login session

There is no need for you too literally access the clients site via the subdomain. You just need to make CI think you are accessing it via that subdomain. And of course make sure only you as the super admin can do this form the main domain
Reply

#18
Thanks for the suggestion, I'll look to see how much work that'll be to change the routing like that.

I suppose that means it's not possible to change the session cookie domain to something other than what is initially set in config.
Reply

#19
One solution that might be simpler to achive could be this, it may or may not work in your specific scenario but i'm assuming your client applications have their own set of users they can sign in as.

On the master application, build in a method to generate a random token (e.g sha256 + openssl_random_pseudo_bytes ), and insert that into the clients database along with the user id of the user on the client's site you want to sign in as.

Then open a new tab / window to the clients site and build a method on your client application which takes this token as an input. The client application can then look up this token in it's own database, and fetch the user id you're trying to sign in as.

Adjust your authentication system on your client application to allow you to sign in as any user just by specifying the user_id as an input, when you receive a valid token and have your user id, you can then authenticate to your client site without needing to know the users actual password.

Its really important that when you do this you do not provide any other means of accessing this alternative authentication method outside the scope of the token authentication, introducing the possibility of someone being able to sign in as any user just by modifying the 'standard' user/pass sign in form in their browser and passing a user_id=123 input through on that form.

You may want to do additional checks when performing this task like making sure the token was created within the last 10 seconds or so, and also make sure you destroy the token from the database (as well as any 'expired' tokens that may be lurking) so they can't be used at a later date. Each token you generate must be a one-time-use only thing.

Because only authenticated users on your master application can generate these tokens, you can assume on the client application that if a valid token exists, it must be authorised.

This saves you having to mess around with cookies and sharing sessions between your different applications and may be a simpler solution. If implemented properly you should end up with a button you can click on your master application that will sign you in as any user on any client application securely with one click.

So in short you might do something like this:

Code:
* click 'sign-in as user' button on your master application and go to:
https://master.app.com/generate_auth_token/client_id/client_user_id
* generate your token and insert it into client_id's database along with the client_user_id and redirect to:
https://client123.app.com/token_auth/your_token_goes_here
* lookup the token, check it's valid, destroy it and authenticate as client_user_id if everything checks out
* proceed using your app as you would if the user had signed in with their user/pass
Reply

#20
Appreciate the suggestion! Managed to implement something similar to this in my app without any issues.

Thanks for the help!
Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.