This week we have a few new UI features to announce, requested by some of our users.  Thanks for helping us improve!

1.  Bulk Delete

Bulk Delete is a simple way to delete many users or orgs at once.  When looking at a user (or org) list, just highlight and click the user icon on the left.  A red checkmark replaces the user icon and a box at the top of the column counts the number of highlighted users, deleting them when you are ready.  It’s simple, intuitive, and will save time for you and your team.

2.  Test Emails

It’s common for our users to have AuthRocket trigger an email when a user logs into his/her account (or for any other event you choose).  This helps to ensure the security of your app.  We’ve made the process as easy as possible.  Triggered emails do not require any code to set up.

Just go to: Settings > Emails and click +Add email in the top right corner.  Then choose the event that you want to trigger an automated email.

The email is already premade for you but you can easily modify it to suit your needs, both text and/or html.

When done, click save.

Now send a test email with one click.  No fussing around with having to add your email and/or test variables each time.  The email is automatically sent to you, the user who is currently logged in.  Then check your inbox and make sure your email looks how you want it to.

See?  Nothing to it.

Any questions/comments?  Drop us a line.

This week we’ve added Github and Yahoo to our list of social auth providers which already include LinkedIn, Google, and Facebook.  So now there are five for you to choose from.

All social auth providers are available in all AuthRocket plans with full functionality.

This is a good space to show you just how easy it is to enable a social auth provider with AuthRocket.  For anyone with standard logins working with AuthRocket, adding a social auth provider takes no additional code.  It works like this:

Step 1

In the AuthRocket UI, simply turn it on.

Step 2

Register your app with your chosen social auth provider.

The signup is easy and takes between 2 and 10 minutes, depending on which social auth provider you are adding.  You’ll need to register your homepage URL and a few other things.

Step 3

Tell AuthRocket about your app.

This is as simple as a copy/paste of the Client ID and the Client Secret (Which you’ll get when you register your app in step 2).

That’s it!

Any questions?  Let us know how we can help you get social auth working with your app.

Today we’re announcing the addition of two key features which make SSO with AuthRocket more powerful and versatile than ever.  They work with LoginRocket, our turnkey solution for logins and signups.

Login State Tracking

Until now, every time a user arrives at a LoginRocket login page, they have to login again.  LoginRocket won’t silently re-login a user who still has an unexpired session.  Our new login state tracking changes that.

With login state tracking, LoginRocket will remember the user’s login.  Each time the user arrives at the login page, LoginRocket will first check for an unexpired session.  If found, the user will automatically be logged back into the app without having to login again.

This feature is enabled with a single click.

Flexible Redirects

Every Connected App within LoginRocket has a Login Handler URL, where a user is redirected after a successful login.  Managing multiple destinations has required adding multiple Connected Apps, each with its own Login Handler.

This option remains available, but to it we’ve now added the ability to define multiple allowed redirect URIs for each Connected App.  Once configured, when sending a user to the login page, include a target redirect URI and, after the login is complete or an existing session is found, the user will be redirected there instead.

This works with a single app, but is especially powerful when used with multiple apps.  When paired with login state tracking, it allows your users to seamlessly jump between multiple apps without being prompted to re-login.

Redirect URIs and login state tracking are part of Enhanced SSO and available on selected plans.

A basic LoginRocket configuration doesn’t require any special handling of redirects and can be accomplished with as little as 10 lines of code.  Customizing your login flow only takes a few extra lines.  To learn more about customizing your login flow using redirects, visit LoginRocket Redirect Handling.

To learn more about these new features and the rest of SSO, visit docs/SSO.

As always, if you have questions or need help implementing SSO, please let us know.  We’d love to help.

Usability is a high value for us.  That includes the usability of our own apps along with how we can help our customers improve their own user experience.

Today let’s talk a little bit about the latter.  Specifically, let’s explore what happens when a user tries to view a page that requires a login.

There are many ways an app can respond to a not-logged-in condition:

1.  It can simply show an error message.  Thankfully this is not particularly common, but it does still happen.  This is not recommended as it creates a dead-end for the user.

2.  The app can redirect the user to login, but returns the user to a main page instead of where they originally intended to go.

This is really common.  Unfortunately, it sends the user on a detour where they have to remember where they were and how to get back there.  The solution is to track where they were so they can be sent back.

3.  The app can redirect the user to login, and even return them to an original page.  However, if two browser tabs were open to different pages and the browser is reloaded, both tabs end up at the same page, not the distinct, original pages.

Often the original page tracking mentioned above is in the form of a session cookie.  The challenge here is with multiple windows or tabs.  As each tab reloads, it overwrites the original cookie.  The user ends up with multiple tabs at the same URL.

Tracking alone, even tracking only one page, helps a lot, as only a minority of users end up with multiple tabs.  However, for power users who work with multiple tabs or windows, it can be a real annoyance.

4.  The app can redirect the user to login, and return each tab to its original place.

Instead of tracking with a cookie, use a query parameter that’s maintained through the login process.  This allows each tab to independently be restored to its original location.

Introducing redir

We’ve added a new parameter to LoginRocket to make it easy to take your app from a level 1 or 2 experience all the way to level 4.  It’s simply called ‘redir’.

‘redir’ is designed to hold a path containing the original page the user wanted to view.  You can pass it as a query parameter to any LoginRocket page and upon successful login (or signup), it will be returned to your app alongside the login token.  Once your app verifies that login and establishes a new session, it can use redir to send the user back to where they wanted to be.

We use redir when you login to manage your AuthRocket account.  If you want to try it out, go to a non-dashboard page (such as viewing a user or a setting page) and then logout.  Log back in and you should be back where you started.

All LoginRocket instances can use redir.  Read more or let us know if you have any questions.

We’ve spent much of the past few months making behind-the-scenes improvements.  Today we get the chance to talk about something much more visible.

We’re excited to announce the availability of Email Verifications.

Many sites and apps want to verify a user’s email address. Instead of handling this yourself, now AuthRocket can take care of all the complications of email verification for you.  As is our style, it takes just a couple of clicks to enable.  You have the option for us to handle everything from tracking the verification state, to generating tokens and sending out emails, to blocking logins until verification is complete.

Email verifications + LoginRocket = One-click to awesome

If you’re using LoginRocket, our hosted logins and signups solution, email verifications are super easy to enable.

1. Go to Settings -> LoginRocket, and ensure Enable Email Verifications is checked (it probably already is). This makes sure the LoginRocket pages that handle verification are enabled.
2. Next, choose if you want to still allow logins when verifications are pending or not. Under Verify Emails for New Users, choose Request to still allow logins, or Require if verification must be complete prior to logging in. This instructs LoginRocket to initiate verification for all new signups as well as whether to allow logins for users whose email verification is still pending.
3. You may be prompted to create an appropriate Email hook to send out the verification emails. Do that if asked.

That’s it!

If you need, you can also now check the user’s email verification state with the new attribute email_verification.

Existing users will not automatically be required or asked to verify. You can use the API or the management portal to initiate email verification for them too.

Email verification APIs

If you aren’t using LoginRocket, we’ve also added new API calls (both the AuthRocket API and the LoginRocket API to help you glue everything together. There are also two new events that are generated as part of the user’s lifecycle.

authrocket.js has also been updated.

For more details, see the API documentation or contact us.