Warning

The XML-RPC API is deprecated, and will be removed on July 1, 2023.

Please use the REST API instead.

Contact support if you need help with migration, or need the feature enabled on a transitional basis.

Login Token

We've added an API call that returns a token that logs a user into ActionKit. This is useful for integrating your own login system with ActionKit's.

Warning

Please be careful where you use the token and read the cautions below. Misuse could lead to leaking your end user's information.

How

Required parameter:

id - a user ID

Optional parameter:

seconds - seconds until token expires (default=86400, one day).
86400*30, or 30 days, is the max .

Returns:

i - a string you can use in an ActionKit URL (e.g., act.you.org/event/campaignname/123/host/?i=[token]&l=1)

(note the &l=1, which keeps ActionKit from asking the user to set a password first.)

Errors: DoesNotExist

Cautions

You should be careful where you use the token:

  • ONLY give the token to users who are logged into your system. An akid= or a new user's email address isn't enough.
  • If you email the token, warn the user that forwarding the link will compromise their account. (event_email_created.html has sample warning text.)
  • Use the default 1-day expiration period if you can. For example, it should work for a redirect or link to ActionKit in your site's UI. If needed you can use up to 30 days.

Securing tokens is important because if one leaks (for instance, if a user forwards an email with token), anyone could use it to:

  • See the victim's street address, phone number, etc.
  • View or cancel the victim's recurring donations
  • Edit the victim's in-person events and email event attendees
  • Use any future ActionKit features that require login

Finally, be sure your login system is secure. Some basics:

  • If there's a login system provided by your framework, you may want to use it rather than roll your own, both for security and simplicity.
  • We suggest hashing the user's password, not storing the raw password in the user's cookies or the database.
  • Require users to confirm their email address by mailing them a link with a secret token in it. This means, for instance, that you can't let new users "log in" the first time without confirming their email.
  • Your password change token also must not be 'browsable': just adding 1 to the user's ID shouldn't give access to another user's account.