Forum Replies Created

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter sslaughter

    (@sslaughter)

    Semi Update/Hack for this.

    The Validate endpoint was successful in our PRO environment (my local must have not had all the permissions set correctly in .httaccss), but when I tried to retrieve user information (using WP API v2) I would get an error message saying I had not logged in yet. Acting like the Auth was not being passed along to WP API v2

    I saw this on the wp-api-jwt-auth plugins github “issues” page:
    https://github.com/Tmeister/wp-api-jwt-auth/issues/6

    Hey, thanks for this great plugin. I’m having an issue that I need to add:

    add_filter( ‘rest_authentication_errors’, ‘__return_true’ );

    Which forcing WP API to skip the cookie authentication to get the JWT auth work. Or the response will always be something like ‘rest_not_logged_in’ (status 401).

    Is it just me or it is the right way to get this plugin to work?

    P.S. I’m using the latest WP API v2 beta 4 and the develop branch, both not working without adding this filter.

    After putting add_filter( ‘rest_authentication_errors’, ‘__return_true’ ); to my themes functions.php I can retrieve the user info – but there looks like some weird redirection is going on – but that is more of a WP API V2 issue than it is wp-api-jwt-auth’s

    Thread Starter sslaughter

    (@sslaughter)

    Thanks, I got it resolved though.

    My issue ended up being that by default the setting is “Live” instead of “Demo” when you initially install the plugin. It looked like it was a value for “Auto Submit Payment” because of the way the values are laid out in the settings page

    x Auto Submit Payment
    Live or Demo : Demo

    But it was just the “Live or Demo” value.

    === Ignore the below if you want, it falls under “feature” request ======

    One thing it would be nice of you to work on is to make a separate “Save” button for the “Payment Page ID” and “Transaction Key” values. Right now there is just the “Generate HTML” button, which saves those values – and then stomps on the previous HTML Form value.

    We have customized the HTML Form a little bit, so when I have to change the Payment Page ID from its DEMO value to its real value, I have to remember to first copy the HTML, and then edit to put it back in place. I’m pretty sure that sometime soon, someone else not knowing about this will go to change the “Payment Page ID”, and wipe out the form.

    Also – to make the form code a “little” more portable – instead of hard-coding the plugin path for the confirm.php file in the forms “action=” tag you could use plugin_dir_url

    <form method=’POST’ action='<?php echo plugin_dir_url( __FILE__ ) ?>confirm.php’>

    This makes it a little more portable for those who modify their forms and who want to move it from test servers to production servers

    (Our issue is compounded by the fact that we have Developer, Test, and PRO servers, so that is 2 deploys, each requiring some human intervention and setup)

    Thread Starter sslaughter

    (@sslaughter)

    I found out what was going wrong. By default. after installing the plugin the “Auto Submit Payment” value is set to “Live”. After changing it to “Demo” things started processing correctly.

    Just wish the error message had been a little easier to figure out.

    Thread Starter sslaughter

    (@sslaughter)

    So – any one else experiencing this problem ? Any ideas on what is going on ?

    Thread Starter sslaughter

    (@sslaughter)

    That did it. My wp-config had debug on for some reason. The Admins who set up the VM must have configured this way by default.

Viewing 5 replies - 1 through 5 (of 5 total)