10 jun

New week! Gonna be a short one since I’m taking Friday off for Shelley’s wedding!

The plan for the week is to get the apps I tested last week into a docker container with wordpress and see what happens. In theory, this shouldn’t be a problem. I have a working wordpress docker container and a working docker container with the apps… now to get them to work together? Or create a new hybrid version? I found the WP database in adminer (wordpress-www)… I wonder how much of this I need to make the whole thing work in docker? Maybe I should start with the dev site data?

wp docker

Took a bit of doing, but I think I have it figured out now. Everything’s up and running… and I need to publish this to a private repo because I don’t want to lose it or screw it up and not be able to undo it.

Well, I tried to put it in github, but there were too many obstacles. This repo would’ve needed a submodule since the WP theme is actually another github repo. I was tempted to delete all the git information and push it anyway, but there are so many crazy vendor files/packages in there that would need to be ignored that it wasn’t worth the trouble of doing the whole thing. So, nvm, I guess.

Good news, tho: all the homepage apps are now loading and successfully serving GET endpoints so that this docker wp image looks just like the dev site. Woo! I need to import the rest of the apps and find out where they’re being served in the rest of the site.

I also need to ask Steven how he added that app management widget to the backend so I can get that going in the docker container. I assume I can find it somewhere in the production wordpress build, but what would it even be called?

Decided to copy all the currently activated plugins from the production server to the docker app. I’m not sure what they all do, but it’s probably something I need to be aware of for this migration. I was hoping one of these would be the thing that controlled the “UA Lib WebApps” icon in the header of the admin dashboard, but that’s not the case as far as I can tell.

So maybe tomorrow I continue on this copying some stuff from the production server journey. Then I can export all the post/plugin data and try to import some of it to the docker version and see what sticks.

11 jun

I’m trying to figure out this admin bar user group menu, but it seems like a giant mobius strip catch-22 situation. The menu won’t show up unless I’m in these user groups, but how do I set myself as a member of the user group if there’s no menu??? I’m assuming I need to add myself to the user groups database… but yuck.

I added myself to the webapps_userGroups database like this:

insert into userGroups (name, wpLogin, groups) values ("Caryl Wyatt", "cewyatt", 2047);

So I’m in the database now, but the admin bar menu still isn’t showing up, so there must be something else going on.

I started going function by function through the userGroupsAdmin index.php/functions.php, and there’s definitely something going on with JWT. I var_dumped the apache_request_headers() in gGetTokenJWT() function, and it’s missing the ‘Authorization’ header. Where is that set, I wonder?

I just fell into a very deep hole of complication. Lots of moving parts, here:

• manage app:
  • manage.js which I think is the factory for the API and handles authentication
  • manageUserGroups.js which I think is the front-end for adding/deleting users
• userGroupsAdmin API that handles all the backend/database info…
• JWT php library – has nothing to do with WP specifically, but our code interacts with it via WP almost exclusively

I’m not even sure where to start with all this, but I have to dig in somewhere. I think I’m missing something fundamental about http headers or requests or something. After some googling, I tried adding a few lines about authorization to the userGroupsAdmin .htaccess file because lots of people on stack overflow said that was what was holding back their auth headers. I don’t know enough about the whole process to even know whether or not I should have one? Is that set somewhere else in the code? Is JWT doing that somewhere? I can’t figure it out. But I have to have an authorization header present in order to create a UALib JWT token. How is this working in production?

Well, I went to go view the http headers in the live site, and realized that the docker wp site now has the admin bar menu for webapps! I have no idea when that happened, but I’m glad it’s showing up.

Comparing the console statements between the live and docker versions is going to be very helpful, I think. There’s a whole list of stuff that the live site has in its console that the docker site is missing: ‘Token saved, authenticated, token saved, WP user list received’ etc. The docker site console stops before the first ‘Token saved’ and tells me it can’t load /wp-json/wp/v2/users/me which is the problem I’ve been working on for the past hour or so. So at least I’m on the right track.

12 jun

Today has been really frustrating.

I decided this morning to just focus on the PHP API portion of this issue instead of bouncing back and forth between the app side and the angular/WP side. As I was going through all the code, though, I found that the userGroupsAdmin app is inextricably tied up with the WP API. And the WP API is not being served because of some hold up in the angular code. It definitely has something to do with these dang JWTs and HTTP Request Headers, but I’m really struggling to see how it all fits together.

So there’s this function that seems to be causing most of my problem: gGetTokenJWT() from sGP/functions.php. It’s looking for the HTTP Authorization request header, and it doesn’t set the token unless that already exists. Problem is, I cannot for the LIFE OF ME figure out where that should be set.

I’m super frustrated by it because it’s working on the live site. Like, I log in to wordpress, click the webapps icons in the admin bar, and when I look at the headers, the Authorization and credential/key is RIGHT THERE. But when I log in to the docker wordpress, click the webapps icon in the admin bar, there is no Auth header. And I get back a “connection refused, 505” error from the WP API. So if it’s working in the live site, where the heck do those headers live?! I copied the webapps directory straight from the live server, so I don’t think I have a different version of the apps or something… and I don’t think it’s a plugin, because none of those really fit.

I’m just… so annoyed and frustrated and angry that I can’t figure this out.

To add to it: even when I’m logged in to the live site, the userGroupsAdmin/index.php path gives me the same error: “Session expire, please reload the page!” and doesn’t have an Authorization header. This (along with the WP API connection refusal in the docker site) leads me to believe that this header has to be set somewhere in WP. I guess I’ll focus on that when I return tomorrow.

Just stumbled on this: could also be the wordpress .htaccess file configuration. I’ve been so worried about individual app .htaccess files that I didn’t even think about WP’s file. I’ll check on that tomorrow, too.

13 jun

After some reflection yesterday during my bike ride, I’ve decided to just FTP all the files from the server that pertain to the live site. I’ve been trying to recreate it from a fresh wordpress install, but I’m obviously missing some kind of configuration somewhere. Hopefully this doesn’t screw anything up on the actual live site. Like… I don’t think it’s going to connect to the same database? But that’s the kind of thing I need to be aware of when setting up this docker container.

Now I’m remembering that all the database info is in wp-config.php, so I can just update that stuff. And because it’s in a docker container, it won’t necessarily be able to connect to the actual server, right?

Okay, so I kind of did a hybrid of this plan. I looked through the wordpress-www live site database to see if any of the tables in there might correspond to some kind of secret key for JWT. None of them do. So instead of trying to recreate the entire live site, I just copied the parts of the .htaccess file and wp-config.php file that didn’t match what wordpress already provides.

Then I did some vim grepping to find any mention of headers or authorization, and I found a function in the manage angular app that handles the WP nonce stuff. It’s actually an angular factory: .factory('AuthInterceptor', ...) that depends on the function AuthService, which is the function I’ve been having issues with (so I’m not super surprised). I console logged some stuff and now I’m trying to figure out what it all means, but that obivously means reading some angular documentation because I don’t understand the lingo. Time to figure out what an angular interceptor is and get that ish working.

Alright. I’ve read and console logged my way through the AuthInterceptor factory/function, and it’s none of those pieces that’s holding up the process. It’s definitely still the stupid token that’s supposed to either exist or be created in the AuthService service/function.

In all my console logging, I noticed that the live site sets the ualib.Token in localStorage no problem, which led me to see what else is being held in local storage. One of the items is WP_DATA_USER_118, which is my user ID in the live database. I figured maybe there was some kind of user permission situation going on, so I thought importing the wp_users and wp_usermeta tables to my docker build would be a good thing to try out. I should’ve realized that would be trickier than I thought it would be… my admin dashboard isn’t showing up anymore. And even though I log in using the login info for the user with ID 118, it still thinks I’m user 1. So there must be some other setting somewhere and now I’ve busted the wordpress install pretty bad.

On Monday, I’ll probably need to reinstall worpdress in this container… which is making me sad.

But! I’ve definitely made progress here today. I’ve eliminated a lot of what this problem could’ve been. Now I just need to figure out why the token isn’t being saved to localStorage and why the Authorization header isn’t being sent with the rest of the headers. It really might have something to do with the user permissions and backend settings somewhere, so I should investigate that, too.

It’s just really weird to me that it’s working on the live site but not in my “local” build. That has to mean it’s a configuration or setting somewhere, right? It’s probably not the code. But I need to use the code in order to drill down to where this setting is set. And I’ve at least ruled out the myLocalized script from functions-ualib.php. I’ve also ruled out the interceptor. It’s definitely this authService… but why? And how?