Writing a request spec / test in Rails with authentication

What good is it to have an application if you don't know if it works? By writing automated tests around the most useful/important pieces of your application, you can build with confidence. And if you need to make a change to your code, you can know immediately if it still works.

Using Rspec, I build out an automated request spec to make requests against multiple API endpoints. Each endpoint has a different purpose, and I show how to write tests for both authenticated and unauthenticated users.

🤯 Contribute on Patreon

⏱️ Timestamps:
00:00 - Introduction
00:31 - End result
00:45 - Installing rspec rails
04:19 - spec support - object creators
06:30 - devise specific controllers
09:45 - other files

💌 Newsletter:

🪐Elsewhere:

💭Concepts:
* Rspec
* Request Spec
* Devise
* Authorization
* authenticate_user!

📚Resources:

🎬 Subscribe!

My name is David W Parker and I’m creating and publishing videos on ProgrammingTIL to help teach anyone and everyone who wants to code. I’m a huge fan of Ruby on Rails, Svelte, and WebGL. I’ve used React a lot in the past, as well as some Vue and AngularJS. I’ve done some professional Python and Django as well. I like to create real applications and my tutorials will walk you through how to build something real from beginning-to-end.

#ruby #rails #rubyonrails

[ksikluks]

Great hint with Rspec needing to have "HTTP_JWT_AUD"! Found my way to this video while searching for a solution why my request specs won't work. Great catch!

I'm using the provided test helper btw, so devise/jwt/test_helpers, but in order to make it work I needed to set "JWT_AUD" as well as "HTTP_JWT_AUD" in my headers hash in the tests. The former is probably used by the test helper while the latter is used by Rspec to actually send the correct header.
No need for a workaround in the actual controller code - postman works just fine with sending "JWT_AUD".

BTW: I was asking myself whether "aud" is actually used correctly by the devise-jwt gem. For my understanding according to the jwt docs it's not a "client id" (which is how devise-jwt and probably warden-jwt uses it), but more the audience the token is valid for. So, from my understanding:
client makes sign-in request to the server, which generates jwt and sets(!) aud to the audience where this jwt can be used. For instance: sign-in goes to "login.example.com", aud could be list of ["login.example.com", "www.example.com", "www.example.org"], i.e. all the sites this jwt is valid. Any of those servers then checks an incoming jwt token whether the provided aud contains itself or not. No need for an AUD header (which can be faked anyways).
devise-jwt uses it as a kind-of a client identification where I couldn't find any corresponding claim in the docs.
However I have to admit that reading jwt rfc notes becomes a bit confusing after some time (who is meant by "relying party" etc.).
What's your thought on that?

[heliosh.kamarasov]

Great video series in general, much appreciated! Though this one was a little to much to fast for me, maybe would have been better to break it up into two vids. But your code is thorough AF, top notch sir!

[johnquarto]

Yeah I echo Helios' comment: if you follow the code as presented you cannot get the app to work (nor the tests to pass). You've simply skipped too many intervening steps. If you look at the repo, there's a goodly amount of variance from the code in the video (one example: "ping_request_spec.rb" in the repo is apparently "ping_spec.rb" in the video. Not sure that's the only challenge, but it means there's likely other inconsistencies. And the entire just crashes everything (for me at least). Here's my suggestion: start each video with the repo in a known state. make a branch. put all changes in that branch. A the end of the video save both the branch and a newly merged master. Otherwise there's no good way to know what you're done off-screen.