Add participant login using a query param

[npaton]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem?

We'd like to log in players through the URL, so they don't have to enter their ID in the player creation form.

Describe the solution you'd like

Something like: http://localhost/?participantID=jky6jh3t4kjlfkc23

Describe alternatives you've considered

No response

Teachability, Documentation, Adoption, Migration Strategy

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[JamesPHoughton]

You should be able to do this with a custom PlayerIdForm. I use something like this to get mturk workerIds from the query string, although you'd want to adapt it to whatever the recruiting platform provides (prolific uses different query string parameters for the ID, etc):

// autoPlayerIdForm.jsx
export function AutoPlayerIdForm({ onPlayerID }) {
  const urlParams = new URLSearchParams(window.location.search);
  const paramsObj = Object.fromEntries(urlParams?.entries());
  const workerIdFromURL = paramsObj?.workerId || undefined;

  useEffect(() => {
    console.log(`Auto-submitting ID ${workerIdFromURL} from URL parameter "workerId"`);
    onPlayerID(playerID);
  }, [workerIdFromURL]);

// if the workerIdFromURL is undefined, then display a dialog for manual entry here...

}

and then in App.jsx:

... (other stuff)
    <EmpiricaContext
      playerCreate={AutoPlayerIdForm} // 👈 pass in the new component
      introSteps={introSteps}
      exitSteps={exitSteps}
    >
      <Game />
    </EmpiricaContext>
...

This will still show the player login page, but it will submit and pass through so quickly as to be imperceptible to the user.

My full code is here, but has a lot of other stuff too.

[aridyckovsky]

Is this issue being worked on by anyone right now? I see that PR #187 relates to the query param login. I'm interested in helping with finishing this update if help is wanted.

I also want to extend the player creation procedure to potentially depend on logging in via an external account (e.g., GitHub or a web3 connector like WalletConnect). For instance, if trying to run a series of experiments with GitHub users as players, I'd want to authenticate their account as part of the player creation, tying their account to their player. Ideally the login information can be cached for players to easily return if participating in (a) multiple experiments or (b) a long-term experiment that they come back to multiple times. I assume this will require updates on both client/server sides, since auth flows will need access tokens/secrets stored server-side.

Another part of this account-based player creation would be contingent on particulars of an IRB protocol, so there may need to be flexibility with when/how login flows occur (e.g., before or after signing a consent form for an experiment).

[npaton]

Security of player login is essentially non-existent. Pass any string, and you're in. No auth, no identity verification. We have been operating under the assumption that experiments are short-lived, users are redirected from another system that will tell them what string to pass in, or it will come from the url params. And this was an acceptable compromise for convenience. We haven't heard so far of any abuse here. This simplistic system should probably remain so for most cases. But I'd be very happy to see other, more proper, forms of player authentication added to the system.

Trying to keep it relatively simple and flexible is key though. Just thinking off the top of my head, maybe we could leave authentication itself completely external to the system, and just have an optional flag to pass a private key on the server, that would verify the signature on the the player identifier, which could be a jwt or paseto. The player identification string would contain the signing and an id, so you could correlate players to your external system in post-processing.

Note that player "authentication" is in Tajriba: https://github.com/empiricaly/tajriba

For consent, while it is currently before player login, you can disable it, and then put your consent in your intro steps. If there are better ideas here, I'm open to suggestions.

The auto-login from url params is a separate and much simpler endeavor.

[aridyckovsky]

That makes a lot of sense @npaton, re: types of player authentication and keeping focus on convenience for the most likely mode of experimentation. Your thought to maintain separation between the core system and formal authentication seems like the way to go. Modularity would be important both to keep things simple for most and to help with maintaining the various authentication procedures since service providers may change requirements over time. And thanks for pointing to the Tajriba side of things, I'll have a deeper look when I get a chance.

I assume a formal player authentication module is worth creating a separate feature request for? That can leave this feature update as lower-hanging fruit to finish up quicker. Let me know if that makes sense and I'll open a new issue for formal auth options with reference back to these comments (here or on Tajriba, whichever you think is more appropriate).

[npaton]

It would be great if you were willing to create a separate feature request for external verified auth. And this ticket is just for url param auth. You can create it in this repo, I track everything from here. 🙏