Preface:
So today I decided to resume my work on trying to add this second “API.” I call it that since this will be used mostly with my other applications as a way to connect and share data across them. Anyways, I wanted to take advantage of this new authentication scaffolding that was released with Laravel 8.0. I ran into a slight problem when I tried to implement this new scaffolding with my previously-outdated-now-updated Laravel application which I use as the main resource hub for Antilobby. Since it’s already an application that I’ve worked on a bit, there have been some issues with actually using this new Auth method. So after tinkering with things for a while and accidentally deleting the entire Antilobby database (oops! don’t run php artisan migrate:fresh if you are integrating an existing database with Laravel), I decided that it’s probably not going to be viable to continue trying to use this new Auth method.
Shortly after some brainstorming, I figured… well why not just do a fresh install of Laravel and then try again. It’s likely going to work if I do that. But before I even started doing that, I wanted to see how viable it is to share authentication between multiple Laravel projects. The entire reason why I wanted to deploy this new Auth method is so that I can begin crafting a new secure way to submit data to the Antilobby database. Right now, it’s rather easy to insert any type of data you want if you had the right information. So before I really begin seriously working on this project, I want to iron out ways that people can “hack” this application.
Auth and MVC
An area that I wanted to improve on for my Laravel application since I am still learning it, is to really follow the Model logic used in the Model-View-Controller architecture. After I try out this new authentication scaffolding available to me and get it working, I’ll go ahead and make the new APIs for the Antilobby desktop application. They will support adding data to the Antilobby resource hub so I can really start providing some really cool graphs to you all (or just me ^.^). By creating Models for all of the data I collect, not only will it be easier to use Laravel’s query builder more effectively, but I’ll also be able to use these all of the APIs. So as you see, there is a bit of work to do.
Last but not least… Vhosts.
BUT before I could do any of that work, I had to find a way to deploy a second application on the server that hosts The Resource Hub. In order for me to keep using just one SSL certificate, I need to also proxy the request through Apache, like I do with Antilobby. I had some issues with this since it gets a tiny bit tricky to not only proxy multiple requests but also direct each different request to the appropriate directory. Both applications are located in different directories and also have specific “public” directories within the application itself that must be the root of the application otherwise, people can find out some sensitive information. It took me a few hours of no luck, looking through Apache mod documentation to find a solution that really solved it the way I wanted it to be done. I had been using subfolder directories to proxy these requests and it got tricky when I needed to detect these subdirectories AFTER going through the Apache server. I came back to it today after being able to have my subconscious work at the solution and, voila. Why not just use a different port? Duh. I knew how to redirect a request using different ports and I was pretty sure it wouldn’t have any effect on the end result. Made sure the port was accessible, changed the vhost on both servers, saved, rebooted… tada!
Just one little problem. I ran into a weird redirect that happens if you visit the root proxy directory, it repeats the directory without a slash.
For now, I won’t worry about that since it doesn’t really create a problem.