I use local to host my wordpress api locally and i test my mobile app on my device, and i use live links so my device can connect to my wordpress api. But recently, a change was made that gave live links a username and password, so i can no longer test my api through local! How do i turn this feature off? the old ngrok version worked, but this one doesn’t.
I’d love this feature too
I’d love this feature too +1
I’m here to vote for this feature! I am working on projects that require the site to be “live” for not just webhooks but e.g. for WooCommerce payments that requires JetPack. When I override siteurl
and home
using e.g:
define( 'WP_HOME', "https://username:password@incandescent-grain.localsite.io" );
define( 'WP_SITEURL', "https://username:password@incandescent-grain.localsite.io" );
(Note, I’ve even tried setting siteurl
and home
directly in the DB too)
…you can see that having to include the username:password
bit causes issues with CORS.
Hi all - thanks for context! Short answer, there isn’t a way to do this today; the Live Links require that username and password. Here is a feature request for turning that off that you can upvote - Live Links - Disable Password Authentication
That said, I’d like to learn more about your workflows. @aubreypwd can you expand on your use case a bit? Is there a reason that you use Live Links versus running the site locally on your machine (either at mysite.local or localhost:10001)? Based on your description, I’m not sure if you run into issues when only running the site locally.
Is there a reason that you use Live Links versus running the site locally on your machine
My case is that I need to setup WooCommerce payments locally to debug an issue when processing payments. But, WooCommerce payments requires Jetpack to do some heavy lifting now and Jetpack requires the site to be “accessible”
But, that aside, being able to mimic a live site for webhooks, etc would be a great ability to do in local, but for my current specific case, I either need to be able to:
- Set my
siteurl
andhome
to include theusername:password@
bits (which as you can see above doesn’t work) - I need to be able to enable my site to be live by using empty
username
andpasswords
in live links
I think a username:password
should be on by default, but I also think I should be able to empty those out to be able to not have to use them in URL’s. Or, at a minimum I should be able to include them in siteurl
and home
to mimic a live site, but the errors above not happen.
Again, being able to mimic a live site would be super useful in so many cases.
Oh, and yes, locally I cannot setup WooCommerce payments because JetPack requires the site to be live to work. I could accomplish this with ngrok
but I would like to do this with Local since I get a persistent link.
Similar use-case as @aubreypwd above. Need to test Webhooks from payment gateways such as PayPal, Stripe, Authorize.net etc and various other API’s which provide no way to authenticate when making the request.
Perhaps a customizable parameter that could be appended to the live-link might work in my case (not sure about Jetpack though) where the live-links authentication was disabled if this secret parameter was set in the URI.
Hi @ austinwendt, my use case is that I am developing a WooCommerce payment gateway where communication from the gateway sandbox to my app is via webhooks, so I need the Webhook URL to be publicly accessible without password (as @ aubreypwd pointed out, using basic authentication notation of username:password messes with CORS). I’ve voted for the feature but if you search “Live Link Password” in the forum, you can see that this issue has come up repeatedly since passwords were introduced.
The use case obviously is for webhook.
The live link password makes the access blocked and required additional adjustment on the request header. It’s impossible to make adjustments on the request sender server because we don’t have access to it (PayPal, WordPress Jetpack, and Github webhook)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.