Has anyone authenticated against a wordpress DB with a Xojo web app?
I am loading the app through an iframe within wordpress, so its all on the same server.
I have found the mechanism to do it in PHP and a few API plugins but wonder what others might have done in this instance?
The only thing I can say is I did it against Joomla. I couldn’t go straight to the mysql file as they do some odd magic against the hash and salt etc, so I created a rudimentary joomla component, and I send the username/password (via SSL) to the joomla site, it them returns a simple JSON string which gives me UserID, name and what user levels they authenticate against.
Does Wordpress do similar, in other words makes it easier for a plugin to authenticate and return what you want.
Hope this helps a bit.
Coming from Joomla world (where I cut my teeth) into wordpress was like being on an alien planet!
Interestingly wordpress claim they salt, yet I cant see one in the db - that’s going to make things hard!
They have a users table and a users_meta table in which data is stored serially.
My ultimate goal is to just have an algorithm to check hash values between user input and db value for authentication.
I prefer not to go plugin, JSON, cookie etc
Looks like I have some sleepless nights trying to reverse engineer PHP.
A bit late to the party here. Was planning to add functionality like this to GraffitiSuite, and found this thread via search to see if it had been done. Wordpress salts are stored in wp-config.php in the Wordpress root. You could quickly create a plugin to handle this.
Heck, just remembered I wrote a blog post a while back that might help you along if you want to just build a plugin to check the wp_users DB:
From there, it’s just hooking it all up in a plugin and the logic specifics. I think you would like use wp_die() to kill the WP execution after you’ve output what you want to send to your application, but I’ve not tested it or played with this sort of output from a WP plugin in a while.
Revisiting to see if there was a response, and decided to add a link to the Wordpress API Codex home, so you don’t have to dig through the scripts.
Hope these responses help you out.
After a bit of digging and messing around I found a crude yet effective way to authenticate.
My app lives on a corp intranet so it is impossible to show anyone.
I setup wordpress authenticating against AD, fairly painless as I used a simple plugin - terminology was the only problem getting it to work. Now users belonging to a security group I created on AD are allowed to create an account in wordpress - I simply put a login link in the menu and redirected them after logging in to my app. My app loads in an iframe as mentioned prior and will show basically a db front end. Info is searchable weather they are logged in or not. To authenticate (and consequently endit the data) I check for a cookie “wp_logged_in_HASH” (‘HASH’ is an actual hash) set by wordpress that has the unique feature of always having the same hash. The value is USERNAME|HASH so I simply take the left part before the pipe and I have the users name. I then pass in any ACL I might need to implement and hey presto! When logging out the cookie is destroyed and its only available to the IP address it was created from. Not perfect authentication but its centrally managed and it works.
That certainly should work well for single sign-in on an intranet-only application. Though it’s important to note that should such an app be deployed to a server on the internet, you’d really need to do more authentication to ensure that the user does have access to view data. I’ve obviously not seen the code, but I can think of at least one way I might be able to fool the app in to giving me more access than I should rightfully have.
At any rate, kudos to you for finding a solution that fits your needs!
We are dealing with accountants and property teams for now - I doubt they can fake a cookie!
When we venture into the big bad net this method will not be used.
Its simply a mock up for what is effectively a proof of concept.
It should also be noted that changing the salt etc in wp.php or whereever it is will break the code.
You will need to be able to view cookie data to achieve this or you could guess what the cookies name is (let me know how that goes if you try :P).