Developer Jess

Greetings!  Long time it has been.  Today's post comes from a project I was handed to convert the tens of thousands of users through our website that are using social accounts into email/password logins.  It has served us well over the years, but with the on-going scrutiny from the changes at Facebook, and the integration we need to do with our online shop which does not have social authentication - makes sense it is time to remove. But what is the cleanest way? We want to make this as seamless and easy as possible for our customers and with one EDM delivery.  I have come up with the following procedure: The comments should make it fairly self-explanatory.  What you may find interesting is that we are deleting the corresponding user from Wordpress .  This will get re-created after they sign in with the new user ID.  If you are curious on the SQL that can be used to look up and delete the user by the Auth0 user_id, you can use this query: From there you...

Before I get in to the solution of this article, let me tell you how it started and fill you in on the problem that arose.  I wrote a procedure to get daily deltas of users - those of which who had created/updated their account on the given day (and including the day before for good measure on the GMT timestamp).  The simple search criteria was just the following: updated_at:[yyyy-mm-dd TO yyyy-mm-dd] Simple, right?  the []'s being the dates are inclusive, while using {} would mean exclusively.  Auth0 lets you mix these on either side depending on your use.  While this is all well and good, Auth0 will limit the number of results (even with paging) to 1000 only. So, your first option is that you could have your procedure create a user export job, and then parsing through the results and eliminating those which do not meet your updated_at search criteria.  I can tell you first hand that eventually the amount of users will just get to be too much and cumb...

 Today I write this entry after a few late nights of personal research.  I am building an app and an important part of it will be to integrate it to other services using Zapier .  To do that, I need to make a REST-ful API layer with no login form, but instead to have an authorize routine which can take the user's credentials and to pass back an Access Token . Up until now, other services I have helped establish have either used the Universal Login method, or simply with my own custom Javascript wrapper using the SDK .  Neither of these solutions is going to fit my need.  I did understand that from all of the available methods it had to offer, OAuth was going to fit it in some way, but I did not quite understand how I would evade having to use a login UI element. I've now had more of a solid read over the Auth0 Authentication API documentation, and on the subject of Get Token , there are number of different types of login flows, the main key/value that determi...

It occurred to me that I never actually got into the nitty-gritty of my last post with some JavaScript code examples, and how easy it can be without being restricted to using templates that you need to force to make work. Take these first scripts: First, after including the API required, the first part is simply declaring your Domain and Client ID which you can find from the application's dashboard. The next two functions, _connectSocial and _login .  Are very similar.  The first takes a string of the social you would like to link (providing you have enabled it in your application within Auth0), and produces a popup modal for the user to enter their credentials. The second function allows you to simply pass a username and password which you can use values from a form you create.  You'll notice for both functions, it has a parameter it is passing called redirectUri .  Here I am specifying for it to come back to the same page after the authentication has proce...

Tonight I wanted to write about my current journey with moving our user identity management provider (which shall rename nameless), over to Auth0.  I would like to talk about the pitfalls and triumphs as we go.  It's mostly all good - a shame we hadn't done so sooner! Now one of the most attractive attributes is the different methods/connectors that are provided in order to easily integrate your existing system, and I mean they cover just about everything , but this is also a segway to my first - very little - bit of criticism.  From what I see there are two main channels to provide some type of form to present to your user to input their credentials.  By the way, I'm still learning so please feel free to say I'm wrong at any stage. Lock / Universal Login   Hosted Pages There is a mention of a " custom " way to work with Lock, but the customization looks little to be desired.  As to the hosted pages , well, again - correct me if I'm wrong - but it l...