Conferences i/o supports the use of URL parameters for simple integrations with other tools or processes and to create customized experiences.


TABLE OF CONTENTS

Overview

URL parameters allow users to configure apps to pass identification and authorization data for attendees via query string variables. This is a simple way to integrate attendee information from another data source, like an event app, to save attendees from having to enter duplicate information.

 

Initiating the URL identification routine with the identify parameter

This functionality works through a querystring in the URL for an app. For example:

 

https://example.cnf.io/?identify&first_name=John&last_name=Doe&[email protected]&field1=Illinois


The first part of the query string, identify, tells Conferences i/o to initiate the URL identification routine. Subsequent variables are mapped to the user object that exists in Conferences i/o. A full list of URL parameters is available below, and can be used to do things like pass a shared App or Moderation password.

 

After the identification routine runs, the URL is reloaded without the query string, meaning that the query string will not remain visible to the attendee.

 

Default identification and authorization parameters

Note: All of the following parameters are optional.



Parameter NameAttendee Identification Field
first_nameFirst Name (a default field)
last_nameLast Name (a default field)
emailEmail Address (a default field)
name (legacy)[Legacy attribute] Mapped to first name and last name fields
field1Custom field #1
field2 Custom field #2
field3 Custom field #3
field4 Custom field #4
field5 Custom field #5
cnf_idCustomized unique identifier



Parameter NameUse
app_passwordIf the app uses an App Password, it can be submitted here so that the Attendee does not have to enter it
moderator_passwordAuthenticates attendee as a moderator
URL must point to a Session.
admin_passwordAuthenticate attendee as an administrator



Custom Fields 1-5

 

These fields are the “Attendee Required Fields” which are editable in the administration area of the app. If Attendee Required Field #1 is defined as Member ID, and the attendee’s member ID value is passed as field1 in the identification querystring, Conferences i/o will map that value and provide it under the appropriate heading in any reporting.

 

Customized user identifiers (cnf_id)

 

The cnf_id field available as a URL parameter does more than just pass a private user identifier, it also makes it possible to authenticate to a particular user profile. In a more advanced use case, multiple attendees may be using the same device, or the same attendee using multiple devices. When passing a cnf_id parameter as part of the identification routine (in the URL), Conferences i/o will recognize this and assign that profile to the attendee when they join.

 

This functionality may raise concerns when using identifiers that expose business logic (such as incrementing numbers). Conferences i/o recommends using universally unique identifiers (UUID) or hashed identifiers when passing cnf_id via URL.

 

Can this data be spoofed?

 

Yes. Because there is no signing request, someone could spoof identification data by altering the query string variables. For a more secure alternative, please contact [email protected] for more information about advanced authentication capabilities.


Bypassing check-in confirmation with the auto_checkin parameter

To bypass check-in confirmation, add auto_checkin as a URL parameter to any session URL. 


For example:

https://example.cnf.io/sessions/qhw4/?identify&first_name=Lenny&last_name=Learner&[email protected]&auto_checkin


In the above URL, we are passing along identifying information about the learner as URL parameters, and then we're appending the auto_checkin parameter to trigger the check-in bypass.


What are the requirements for bypassing to work?

auto_checkin only works when all of these are true:

  • Standard check-in mode is being used.
  • Check-in is required for the session.
  • The session does not have a check-in code.
  • All required information fields for the learner have data.


What happens if the requirements aren't met?

If standard check-in mode is not enabled, or if check-in is not required for the session, no check-in will be created.


If any of the required fields are missing or empty (blank), or if the session has a check-in code, then the learner will be brought to the confirmation screen.


For example, in this URL the last_name parameter has been left empty:

https://example.cnf.io/sessions/qhw4/?identify&first_name=Sally&last_name=&[email protected]&auto_checkin


What happens if a learner is already checked in?

If a learner is already checked into the linked session, auto_checkin is ignored. The learner simply returns to the session dashboard.


In practice, when would I want to use the auto_checkin URL parameter?

When Conferences i/o into an application or service, use auto_checkin to save learners the hassle of confirming their information.


Bypassing check-out confirmation with the auto_checkout parameter

Check-out confirmation can also be bypassed via the URL, though this is not required and the practical use case of this is less common.


Note that this only works if an attendee is already checked-in to a session, and if there's no checkout code for the session. Note that it won't create a check-in and then immediately check-out that learner.


The URL structure for check-out looks like this: 

https://example.cnf.io/sessions/qhw4/?auto_checkout


After check-out, the attendee will be returned to the session dashboard. There is currently no way to redirect to an alternative location.