I had a working wp-piwik plugin. Its configuration looked like this:
It worked fine. Then I moved the piwik installation to a different location (so I can track more sites).
Now wp-piwik only recognizes the auth key if we're not using a /home... path, but http://analytics... path. And unfortunately it doesn't work - no tracking occurs.
If I give a wrong URL, it sees it's wrong.
If I supply a wrong auth token, it sees it's wrong. So somehow the plugin communicates with piwik.
If I supply piwik location as a /home/piwik/, it doesn't work, and I'm pretty sure it used to work before I updated from 2.3.0 to 2.7.0.
My site works fine with the tracking code. But that is visible in the browser and I don't like that. I don't want the tracking to depend on the user's browser. I don't want the client to know that there's tracking.
If there's manual php code inclusion that I can use. I'd use it, but i'm not very good with php.
The option "Piwik path (PHP API, beta):" works only if I remove the auth token but also doesn't track. the piwik path can only be /home/piwik....
Here's what Support --> "Run test script" gives me:
*** Test 1/2: SitesManager.getSitesWithAtLeastViewAccess ***
Using: cURL
SSL peer verification: enabled
User Agent:
Call: /home/user/piwik_location/?module=API&method=SitesManager.getSitesWithAtLeastViewAccess&format=XML&token_auth= + TOKEN
Result:
Time: 0s
*** Test 2/2: SitesManager.getSitesIdFromSiteUrl ***
Using: cURL
SSL peer verification: enabled
User Agent:
Call: /home/user/piwik_location/?module=API&method=SitesManager.getSitesIdFromSiteUrl&url=http%3A%2F%2Fsite.com&format=XML&token_auth= + TOKEN
Result:
Time: 0s
Any suggestions?
You also have to update the trusted hostname if you move Piwik:
http://piwik.org/faq/troubleshooting/faq_171/
If this does not help, check WP-Piwik's debug script output (see support tab in settings menu).
UPDATE: As discussed here (https://wordpress.org/support/topic/wp-piwik-recognizes-the-key-but-doesnt-track-with-piwik-url-or-piwik-path?replies=7), the plugin's behavior is as expected. The test script output above shows the wrong value for Piwik URL (it contains the path instead). If entering the Piwik URL and enabling the tracking script, the tracking works.
Related
I am attempting to create a program which uses a user's Spotify data. I've conducted the following steps as per the documentation:
Set up application
Registered redirect urls on application dashboard
Obtained Client ID and secret.
The code I'm trying to use to get authentication is below:
client_id <- "<CLIENT_ID>"
redirect_url <- "http://localhost:8888/callback/"
link <- glue::glue('https://accounts.spotify.com/authorize?client_id={client_id}&response_type=code&redirect_uri={redirect_url}&scope=user-top-read playlist-modify-public playlist-modify-private user-read-private user-library-read user-library-modify')
browseURL(link,
browser = getOption("browser"),
encodeIfNeeded = FALSE)
I was able to get it to show an authorization page once, I tried to approve the application and received a localhost connection error (Connection Refused). This error now happens upon running the code (no authorization page generated).
I've gone through all the steps to fix this issue (Flushing DNS, Disabling Firewall, different redirect urls, resetting my router), but nothing seems to work.
Does anyone have any suggestions on what I might be doing wrong?
I think the proper way of doing OAuth 2.0 authentication is via the httr::oauth2.0_* family. They do not show an example for Spotify, but it should be rather straight forward to set the "dance" up with this framework.
Type demo("oauth2-github") (or refer to the Code repo on GitHub) for an example using Oauth 2.0 for GitHub and adapt the code for Spotify. Be aware that httr provides a convenience function (oauth_endpoints) for some providers (but not Spotify). Hence, you have to provide the necessary config (mainly the proper URLs) using oauth_endpoint (Note the missing s).
If you have particular questions, come back with some code and I am sure we cna help.
Let's say I use the website: redacted.com
Website works fine when I am using it normally.
When I start using BURP SUITE PROXY to intercept requests, I start to have this error:
[2021-04-14T02:45:46.724Z] #firebase/firestore: Firestore (7.24.0): Could not reach Cloud Firestore backend. Backend didn't respond within 10 seconds.
This typically indicates that your device does not have a healthy Internet connection at the moment. The client will operate in offline mode until it is able to successfully connect to the backend.
Error: Uncaught (in promise): FirebaseError: [code=unavailable]: Failed to get document because the client is offline.
Please provide me the solution to this.
The answers do not work anymore due to the Firebase updates - i will give you a short instruction on how to find your custom match-replace rule:
make sure to activate "Intercept Server Responses" in the proxy options tab.
go "intercept" tab
set your burp proxy to "intercept is on"
type "this.forceLongPolling" in the search bar on the bottom
forward the requests until you find a match
there should be a pretty big response file containing something like this:
constructor(t,o,u,p,D,Q,Te,it){
this.databaseId=t,this.appId=o,this.persistenceKey=u,this.host=p,this.ssl=D,this.forceLongPolling=Q,this.autoDetectLongPolling=Te,this.useFetchStreams=it
}
in my case it contains the string "this.forceLongPolling=Q"
now create a match replace rule for this very special string to replace "this.forceLongPolling=Q" with "this.forceLongPolling=true" and make sure to choose "response body" as type:
Screenshot Rule
Using the idea of this troubleshoot (https://github.com/firebase/firebase-js-sdk/issues/1190#), i made the following Match and Replace in my Burp Suite and it worked!
this.forceLongPolling=void 0!==t.experimentalForceLongPolling&&t.experimentalForceLongPolling
to
this.forceLongPolling=true
And someone said before
This can change depending on the version of firebase-js-sdk so it's best to look around for experimentalForceLongPolling within your JS files and make sure it gets enabled.
Workaround for this issue (source).
For Burp, the following match and replace worked for me:
this.experimentalForceLongPolling=!!t.experimentalForceLongPolling
to
this.experimentalForceLongPolling=true
This can change depending on the version of firebase-js-sdk so it's best to look around for experimentalForceLongPolling within your JS files and make sure it gets enabled.
Faced the same issue. What worked for me is adding “firestore.googleapis.com” to the “No proxy for” option in Firefox’s proxy configuration.
Firefox Proxy Configuration
I was hired to write a wordpress plugin which involves an ajax request to the website's eventespresso api.
I got it working fine locally (calling the live site's api from my local server), but when I activate the plugin on the live site, it throws:
Failed to load http://example.com/wp-json/ee/v4.8.36/events: The
'Access-Control-Allow-Origin' header has a value 'http://opt.local'
that is not equal to the supplied origin. Origin
'http://www.example.com' is therefore not allowed access.
My local domain is "http://opt.local", and the live site is http://example.com.
This error suggests to me that it only wants to allow access from my local setup, and not from the live site, which isn't even cross origin! Maybe I caused it to cache the wrong thing in development?
So a few more tests revealed that the cors settings are correct for everything except the specific route I need.
> curl -I "http://example.com/wp-json"
Access-Control-Allow-Origin: http://example.com
> curl -I "http://example.com/wp-json/ee/v4.8.36"
Access-Control-Allow-Origin: http://example.com
> curl -I "http://example.com/wp-json/ee/v4.8.36/events"
Access-Control-Allow-Origin: http://opt.local
I was able to make it work by using ee/v4.8.35 (a lower api patch version) but hopefully, there is a better solution.
I helped develop the EE4 REST API.
Ya it sounds like some issue where the webserver or a proxy or something is caching the Access-Control-Allow-Origin header.
There's no code in the EE4 REST API that controls that header, that's actually handled by the WP API (on which the EE4 REST API is built).
The relevant code is in wp-includes/rest-api.php in the function rest_send_cors_headers(). That calls get_http_origin(), whose value can be filtered using the filter http_origin.
So you might want to try adding something like
function my_plugin_force_correct_http_origin($http_origin) {
return 'http://example.com';
}
add_filter('http_origin', 'my_plugin_force_correct_http_origin');
that will ensure the PHP code is sending the correct Access-Control-Allow-Origin header.
If that doesn't resolve the issue, I would verify rest_send_cors_headers() is getting called at all (you could temporarily put a line like echo 'called rest_send_cors_headers!';die; inside that function to check).
If it is getting called, and my suggested filter doesn't help, you could try tagging your question with 'wordpress-rest-api'. Also, I would be curious to see if http://example.com/wp-json/ee/v4.8.36/events?limit=50 has the same problem.
I set up my own hosted phabricator, everything is working fine (Diffusion repo etc)
I ran into problem after I installed arcanist on my dev box and run 'arc install-certificate', got exception as following:
rying to connect to server...
LOGIN TO PHABRICATOR
Open this page in your browser and login to Phabricator if necessary:
http:///conduit/login/
Then paste the API Token on that page below.
Paste API Token from that page: cli-e644viducdcccrge4i7zo5nfa66d
Usage Exception: The token "cli-e644viducdcccrge4i7zo5nfa66d" is not a valid API Token. The server returned this response when trying to use it as a token: ERR-CONDUIT-CORE: Attempting to access attached data on PhabricatorUser (via getAwayUntil()), but the data is not actually attached. Before accessing attachable data on an object, you must load and attach it.
I am wondering what's might go wrong? Thank you very much for your insights!
I've seen this problem occur many times with our users. In every case so far, the problem has been that users have set up the phabricator uri incorrectly.
Suggestion:
Check your project .arcconfig or your global .arcrc files (if you're doing this outside a project).
Verify that the URI to your Phabricator site is correct. The typical issue I've seen is accessing using http:// rather than https://
What is to be done?
We have an application deployed on the Sharepoint (corporate) Server which uses the windows credentials to log into the application.
App URL format: http://testmachine:1000/sites/test/
Windows Credentials Format: user_id#domain.co.in
The objective is to perform the load/performance testing on the application (especially the log in functionality) for such n number of users.
Normally when I hit the app URL in the Firefox/IE, it pops up a window asking for credentials. I enter the credentials, browse the app and then log out. I intend to capture this in JMeter and simulate this for large number of users.
Where I’m stuck?
Now I start the JMeter proxy server, and then try the same steps as above. But when the pop up window appears, JMeter simply doesn’t record the it nor it does record anything else after the login.
What I’ve tried?
If I try the same steps after enabling “Automatically detect intranet network” in IE, then it simply auto detects my windows credentials (No credentials pop-up), logs me into the app (this is not recorded in JMeter either) and takes me to the home page. And any page thereafter I hit gets recorded in JMeter.
I’ve also tried to use the HTTP Authorization Manager using following parameters:
BaseURL : http://testmachine:1000/sites/test/
Username: DOMAIN\USER_ID
Password: i_wont_tell_you
Domain: \
Realm:
It didn't help. I am quite confused about how-to-use the above element. And not even sure whether its a right approach to get the solution to my problem.
Any help/suggestions?
P.S. I know about a tool called Badboy, but have to go for it as a last resource. Also not even sure if it records the pop windows.
And sorry if the post is verbose.
UPDATE:
I have also tried -
Username: USER_ID and Domain: my_company_domain
But this is not the actual problem. Problem is, when I try to hit the pages (automation) which I've recorded previously return success response even if I haven't used the HTTP Authorization Manager. I'm not sure what I'm missing.
OK. Finally I got what was missing.
First, I had to change the implementation of every request to HttpClient3.1
Second, it was really frustrating to see that JMeter documentation was misleading.
It says that the config file httpclient.parameters, should be edited as following:
http.authentication.preemptive$Boolean=false
But it didn't work. Changing it to true worked like a charm.
Hope this helps other people.
JMeter works at the HTTP layer so the proxy will only capture requests made over this protocol layer. It sounds to me like you have already found the right approach to use for recording by using '“Automatically detect intranet network” in IE', you can use this method to capture most requests and you will have to figure out authentication manually. How you do this depends on how your application communicates with your server to authenticate a user.