Can a Workflow Log In As a Specific User?

Hey folks…

Is it possible to have a workflow log the current user out, and then log in as a different user? I know I can use the logout and login actions, but I don’t know where to get the password from to log in the new user. I recall there may be some trick around using one of the other Account actions, but I can’t remember how it works or seem to find the post about it.
Thanks!
Antony.

1 Like

Hi Antony

No, you can’t do this through a workflow. You can, however do this through the app builder. Go to the Data section, click the App Data tab and choose All Users. On the left side of the data grid you’ll see a link labelled ‘Run As ->’ When you click that you will be logged in as if you were that user.

Hope this helps!

Kirk

Hi @antony, there’s not workaround to truly log in as a different user via workflow. There are strategies you can use to have one user experience the app as another user would:

  • Create a custom user role system with a data type (e.g. project managers can view team member data)
  • Set up Privacy Rules in the Data tab
  • Pass data between groups and/or pages to load specific content

Depends on what you’re doing, but the user would still be logged in as a separate user.

The only “trick” I’d know of (which I do NOT recommend) is storing the password to a separate, custom text field so that a user can re-log in with someone else’s email and that stored password. There would have to be a super great reason to expose the password like that though. In most cases, that would be an irresponsible handling of user credentials.

Hope that helps.


Gaby at Coaching No Code Apps (formerly Coaching Bubble)

Courses & Products, Tutorials, Private Coaching, and High-level Development

Start Learning Today :mortar_board:

2 Likes

https://puu.sh/CI2kw.png

Yes, but if you assign a temporary password, the user’s regular password is no longer valid. Bubble deletes the previously stored password.

So, if you do this, you’ll need to let the user (who you’re logging in as) know by sending them a password reset or letting them know what the temporary is.

I just want to point out the implications.

well depends on the usecase, this works fine for me to test out ui. and if your app uses just social log-in there is no password.

Of course. Every app is different, and if this makes sense for the app, then go for it! I just don’t want password things to be overlooked if some concepts are not fully understood! :grimacing:

Hey everyone… thanks for all the input, much appreciated!

So my use case is this… I have an app which will have hundreds of paid up users, who will each have thousands of database Things of differing types - Contacts, Events, Invoices and so on. When I add new features to my app, they will often involve some new fields or data types, so a new release will also come with APIs I run which will go through everyone’s data to suitably populate or create the new data elements. I am also thinking about keeping my database tidy, and removing data from users who evaluated my system but are no longer using it - so lots of data deletion that I don’t want to go wrong.

The question is: how to most safely perform those tasks, so with the minimum chance of changing or deleting data I didn’t mean to due to human error in how I write my APIs. This became particularly real to me after Josh’s human error which brought Bubble down for an hour earlier this week!

I have a good set of Privacy settings. Every single data element has a “Subscriber User” field, and the privacy settings only allow data access if you are logged in as that Subscriber User. I also currently have one super user who can do anything through the privacy settings. Being logged in as that user sometimes really scares me!

So with my APIs for data cleansing and updates, I was thinking there were three options:

  1. Run them without Privacy rules.
  2. Run them as my super user.
  3. Run each API actually logged in as the user for who’s data I’m cleansing or updating.

Options (1) and (2) seem to open me to the possibility of accidentally deleting or changing data I didn’t mean to.

Option (3) would protect me from that through the privacy settings and therefore feels much safer.

I know I could run option (3) by actually logging in as the user manually… but I was hoping to find a way of automating option (3) for a list of users, as when I get into hundreds of users, doing it by hand will be very tedious.

Oh, and another question comes to mind - if I don’t know the user’s password, then I guess the only way I can log in as them is through the Data tab… is this correct?

So there you have it… any thoughts on my best way ahead would be much appreciated!

Best wishes,
Antony.

Do the data processing as the super user. Test with small batches of test data to make sure your super user’s privacy permissions are set up properly. Grow it from there. Test, test, test.

Don’t work around the concern. Eliminate the concern as best you can.

This is one of those cases where assigning users a temp password to log in as them via workflows is a bad idea. You’re essentially resetting their password without them knowing, forcing you to build a whole thing to make them update their password. How often are they going to put up with that?

Running as them from your back-end would be fine too, but as you said, if this is going to be a big process for many users at a time, then triggering the workflows as a single user who has this type of app-wide access is best. Just make sure your privacy rules are good to go. If you feel like there’s room for error, then break it down more. Spend more time with it. What you described is perfectly possible and you can create perfectly secure rules to make sure that only you can run such batch operations.

Hey Gaby… thanks soooo much for your feedback! I really appreciate your time.

And in fact… as I read your message, I think I came up with a solution!

There is actually another level of indirection in this… in that each of my Subscriber Users can assign any number of other users in their organisation, who are either other users at the same level, or lower level “admin” or “webmaster” users. This is implemented through each user having a “Subscriber User” field indicating who’s organisation they belong to, and another field indicating their privilege level.

So… I can create my own user with the subscriber level privilege, and just keep swapping over who their “Subscriber User” is as my API works on the files of that user… so basically mimicking the actual owner of the files. This means my API won’t be able to accidentally delete anyone else’s files because the privacy settings will prevent that.

I hope that makes sense, and may even be a useful perspective on this kind of situation to you!

Thanks for all your help here and all your awesome videos Gaby… my introduction to Bubble a year ago would have been a much slower and lonelier experience without you!

Best wishes,
Antony. :slight_smile: