Rails 8.0.1 You are in good company

Now, we can hop back in here and go to alphaexitsoftware.io and see....whoops!

There was a 404 here! That's because if we go back to out route file, I have not defined route! And in production, you're not gonna get that screen we saw with the Rails version and the Ruby version, that is only for development.

So in production, you actually need to manually specify the route. So we can go down here, and uncomment this, that sets what the route is going to be, we're just gonna point it to post stud index.

We can save that, check in that save change, and then we can run Kamal deploy again! gcam 'Set root to app';kamal deploy;

And that's basically the rhythm you will be in when you're working on a Rails and application and you're deploying to production.

If we go back here and reload not in production, boom! We are live in production with our whole setup, everything is working, we can upload the active storage files directly to it.

By default, Kamal will use a docker volume to start these things up, but of course, you can configure that, and as I said, you can use S3 if you'd like as well.

Common system is of course these as well, let's add one of those comments, and now we have the entire application running in production, wasn't that easy?

rails g authentication:

Now, let's add authentication to things as well. Authentication is one of the newer feature in Rails, it basically gives you a default setup for tracking sessions, tracking passwords, and even doing password resets.

What it does not give you is a signup flow, because that's usually quite specific to a given application. So, we leave that as an exercise for the reader!

But as you can see here, it adds a handful of migrations, one for users, and one for sessions! So, we're gonna run rails db:migrate again!

And then, we are going to hop in here and have a look at what was actually generated. We have the sessions controller, that's probably the most important. You can see here, it allows unauthenticated access to just new and create.

Everything else by default will be behind the authentication lock! There's also a rate limit to make sure that people don't bombard you with attempts to log into users do not have access to.

And then, we do the authentication using the email address and passwords, and start a new session from there.

If we hop to the session, you can see it just is very basic Rails active record. Now we're gonna set up a default user that the systems should have as we're working with it to allow us to log in since we don't have that signup flow.

So that's just gonna be my email address and 123 password!We hop back into our CLI, and run rails db:seed, that's gonna run that file , I just showed you and set things up.

Now, if we hop back onto local host, and we try to log in with first the wrong password. we're actually gonna see something here , when I added the authentication, it added another gem, it added bcrypt, that's what we're using to keep password secure, so we have to hop back in here and restart our development server!

As we edit a new dependency, we can hop back in ,reload, and now we're good to go here. as you can see, I first tried to put in a wrong password, we're gonna get this screen, try another email address or password.

Now, let's add a way to sign out to the main layout here. we can add that with a button to sign out.it's gonna hit the session path, and it's gonna use a method of delete that session if we're authenticated, as you can see there.

So, it's no gonna show that button if we're not already authenticated, which is good because this layout is also used for login.

All right , let's save that and hop back,and see a reload here, now, we have a sign out button, and we can sign out, and that's all it should be. let's deploy this to production, we're gonna just check this thing into Git, deploy it straight to production, go back to our alpha.software...Oops! That didn't work. Why did that not work?

Because we had not run our DB seeds! Now, I could run DB seed in production, but let me show you another way doing it .

Kamal console:

Kamal also gives you a way to start a console on the server side that is just like the console I showed you earlier that ran in development! You can see here, it reminds you that you are in production.

So, be careful when you create things, that are gonna be created on the server side in your real database.The database, by the way? we haven't talked much about that, and that is because we're using SQLite. So, there is nothing to configure,there's nothing to set up, SQLite is now a suitable database for production with Rails. we have tuned it with all the right pragmas,to run SQLite well in production, you of course still need to set up a way to back that up, but everything else is preconfigured for you.

SO now, we're created that user in production using our Kamal consol! I can log in with that user/pasword.