WooCommerce REST API "woocommerce_rest_cannot_view " - rest

when i paste this link
http://localhost/wordpress/wp-json/wc/v2/products?consumer_key=ck_*******************&consumer_secret=cs_********************
it show for me this error message
{"code":"woocommerce_rest_cannot_view","message":"D\u00e9sol\u00e9, vous ne pouvez pas lister les ressources.","data":{"status":401}}
by the way the cosumers key & secret are correct

Your connection must be throw https
and add this lines to your woocommerce init :
{
....
verifySsl: false,
queryStringAuth: true
}
every post request require ssl
dublicate from this link
Ionic 3 WP-REST API Post request 401 (unauthorized) error
&
WooCommerce REST API "woocommerce_rest_cannot_view "

Here are 2 possible solutions:
Add the following variable in the index.php page of your WordPress installation (Worked for me on my localhost without having to restart the server):
$_SERVER['HTTPS'] = 'on'; //------> Add this line under the line that says: define( 'WP_USE_THEMES', true );
Set the environment variable in the .htaccess file when using Apache:
SetEnv HTTPS on

401 is unauthorized error
if key and secret are correct, it could be todo with SSL
other people report similar problems
https://github.com/woocommerce/woocommerce/issues/19649

Problem solved by adding this line below to the end of .htaccess file
All you need to add this line to .htaccess , this work with me
SetEnv HTTPS on
And make sure use OAuth 1.0 for Authorization

add false in end of creating RestAPI like this...
RestAPI rest = new RestAPI(URL, ConsumerKey, ConsumerSecret, false);
it should by "authorizedHeader"
answer from https://github.com/XiaoFaye/WooCommerce.NET/issues/211

None of the suggestions helped me, so I deleted my previous API credentials and created new ones. This made the change for me.
I don't want to say "just delete your credentials" as you have to make sure to not break any necessary connections, please note that! I'm just sharing my experience on this.

Related

Unable to connect to JIRA over HTTPS server using the Perl JIRA::Client::Automated

I do not use a proxy.
Here is my code:
use JIRA::Client::Automated;
my $jira = JIRA::Client::Automated->new(https://myserver.com, "user", "password");
And the error response is:
Unable to GET /jira/rest/api/latest/issue/DCS-51191: 500 Can't connect
to myserver.com:443 Can't connect to myserver.com:443
Bad file descriptor at
C:/Users/Fred/applis_portables/Strawberry_Perl/perl/vendor/lib/LWP/Protocol/http.pm
line 47.
at createPage2.pl line 16.
Thank you for your help.
It seems that there is a self signed certificate on JIRA server. To bypass, I added following code:
my $jira_ua = $jira->ua();
$jira_ua->ssl_opts( verify_hostname => 0 );
The error doesn't look like a JIRA::Client::Automated error. It's generated by LWP::UserAgent and usually means exactly what is shown.
Do you have a self signed certificate on your server?
Did you try to open that URL in in your browser? https://myserver.com:443 (exactly as you provide it to the module).
Try using curl from your webserver:
curl -vvv https://myserver.com/jira/rest/api/latest/issue/DCS-51191
Maybe it's just a missing www. prefix in your server URL?

Where do you set the identityserver3 endpoint urls?

Are the urls for the endpoints in identityserver3 configurable?
How come in the example for MVC the Authority is set to:
https://localhost:44319/identity
While the standalone webhost (minimal) sample has the authorization endpoint set to:
https://localhost:44333/connect/authorization
Has something been configured somewhere so that the /identity will work.
Or is the .../identity not the IDSrv3 endpoint at all, but rather only the API call instead of
https://localhost:44321/identity
which is what is called in the CallApiController... (I would change this example totally to something else with different names, so that there's a clear difference between what is part of the app (Foo and Bar) and what is part of idsrv3 (auth claims tokens and scopes) --sigh.
(end of question...)??
In any case:
When the webhost standalone minimal idsrv3 is down - I'm getting:
No connection could be made because the target machine actively refused it ... Wasn't sure what I was doing wrong, but was sure that I was doing something wrong. (Forgot to run the IDSrv3)
When its up, in both paths: (/identity and /connect/authorization)
I get 404 not found,
and if I just give the root with a trailing slash, I get: Error, The client application is unknown or is not authorized, instead of showing me the login page...
So it seems the trailing slash root is the correct way to go, which leaves me with my first question, so how/why is the Authority set in the MVC demo to include the path /identity.
IdentityServer url is configured in the startup.cs file.
In the MVC app the IdS is configured under 'webroot'/identity. In The console app IdS is running under the root of the selfhost 'webroot/'
app.Map("/identity", idsrvApp =>
{
idsrvApp.UseIdentityServer(new IdentityServerOptions
{
SiteName = "Embedded IdentityServer",
SigningCertificate = LoadCertificate(),
Factory = new IdentityServerServiceFactory()
.UseInMemoryUsers(Users.Get())
.UseInMemoryClients(Clients.Get())
.UseInMemoryScopes(Scopes.Get()),
AuthenticationOptions = new IdentityServer3.Core.Configuration.AuthenticationOptions
{
EnablePostSignOutAutoRedirect = true,
IdentityProviders = ConfigureIdentityProviders
}
});
});
The other urls you mentioned are all urls which can be resolved via the discovery document: http://'webroot'/.well-known/openid-configuration
or in case of the MVC app: http://'webroot'/identity/.well-known/openid-configuration

Direct Mail: FEHLER Die HTML Inhalten können nicht ausgelesen werden

Since I've changed the Website from http to use https instead, the Newsletter can not be generated anymore in TYPO3.
I'm using following Extension to send the newsletter:
http://typo3.org/extensions/repository/view/direct_mail
Following error message turns up:
FEHLER
Die HTML Inhalten können nicht ausgelesen werden.
I've checked following Settings:
- Error Logs (php and apache), nothing in there
- php settings (allow_url_fopen http://php.net/manual/en/filesystem.configuration.php), setup the way it should
- checked the www's blogs but didn't find a working solution
- the changes for ssl: domain record changed in typo3
- htaccess forward from http to https
- tried to send an external link (didn't work either)
- checked for the boundries
- checked for the right domain-settings
- deprecation log didn't contain anything either
- switched errors on (no alert or message concerning this issue)
- typo3 configuration (curl is still on)
Any Idea how to solve that issue?
I've actually tried several forum settings to solve the issues but didn't get along so far.
is the backend also using https? basically, direct_mail uses the same protocol as TYPO3 BE, except if UseHttpToFetch is activated.
Please check following:
fetch the page manually using wget or curl directly from the server (SSH to the server)
check in the extension config if "UseHttpToFetch" is set.
Last but not least my college once more solved this issue:
There seemed a Core-Bug in:
2328: // PATCH
2329: // CURRENT FILE: typo3/sysext/core/Classes/Utility/GeneralUtility.php
2330: // CONCERNING: typo3_src-6.1.5
2331: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
The message now is: Seite ist erfolgreich ausgelesen.
Thanks for your help guys!
Thanks Nico for that patch!
In my case Direct Mail reported this problem, when I used a HTAccess password.
The easiest way to test it, was to remove this password access for a minute. :)

JENKINS Authentication Fails

I am getting the following error while trying to trigger Jenkins job from any REST Client
Authentication required
<!-- You are authenticated as: anonymous
Groups that you are in:
Permission you need to have (but didn't):
hudson.model.Hudson.Read
... which is implied by: hudson.security.Permission.GenericRead
... which is implied by: hudson.model.Hudson.Administer
-->
</body> </html>
The request is getting triggered while using curl from terminal
I am using the following syntax
http://user:apiToken#jenkins.yourcompany.com/job/your_job/build?token=TOKEN
[ref :https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients]
ie. curl -X POST http://user:apiToken#jenkins.yourcompany.com/job/your_job/build?token=TOKEN
Check this "This build is parameterized " , select the credentials parameter from drop down.
Use this
curl -X POST http://jenkins.rtcamp.com/job/Snapbox/buildWithParameters --user "username:password"
It solved my authentication problem.
I hope it will help others too.
My development team's configuration settings were matrix-based security so I had to find my group and give my group workspace access.
1.Click on Manage Jenkins .
2.Click on Configure Global Security .
3.in matrix-based security change:
Overall - Read
Job - Build
Job - Read
Job - Workspace
Then
POST jobUrl/buildWithParameters HTTP/1.1
Host: user:token
Authorization: Basic dWdlbmxpazo4elhjdmJuTQ==
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
Branch=develop
For me
https://user:password#jenkins.mycompany.org/job/job_name/build?token=my_token
in https://jenkins.mycompany.org/configureSecurity
disable CORS
hope this help
Try using the -u parameter to specify the credentials:
curl -u user:apiToken -X POST http://jenkins.yourcompany.com/job/your_job/build?token=TOKEN
I provided header Authorization parameter with value :
BASIC base_64encoded(username:password) and it worked fine.
Authorization Basic bmltbWljdjpqZX*********
Simply disable "CSRF Protection" in the global Security Options, because those URLs don't send post data identification.
focal point :
username:password#
curl -u user:apiToken -X POST http://username:password#jenkins.yourcompany.com/job/your_job/build?key1=value1&key2=value2 ...
If you are encountering this problem with jenkins api client in ruby.
I figured Jenkins is blocking all the get request, instead use api_post_request.
Also, you have to generate api token because normal password is not working anymore.
#client = JenkinsApi::Client.new(
server_url: "",
username: '',
password: ""
)
SITE_FILE_PATH = 'artifact/target/site'.freeze
#jenkins_uri=''
#jenkins_job_name=''
def latest_test_file_path
"/job/#{#jenkins_job_name}/job/master/lastSuccessfulBuild/#{SITE_FILE_PATH}/Test-Results/test-results.html"
end
puts #client.api_post_request(latest_test_file_path,{},true).body
you can set the parameter true if you want the raw response.
default parameter or passing false will just return response code.
Also make sure to construct the right prefix.
You can refer to the above snipped.

mod_perl basic auth, $r->user() fails

We have a project that uses mod_perl2 and mason.
The problem I'm facing is getting the user authenticated using apache basic auth, from .htaccess .
In cgi enviroment I can get that from $ENV{REMOTE_USER}
In mod_perl I should be able to get it using $r->user(), which unfortunately returns undef.
Also no luck with $r->connection->user()
I've also tried CGI::Apache2::Wrapper, $cgi->remote_user() and $cgi->user_name() again with no luck.
The only way it works is calling $r->headers_in->get('Authorization') which returns something like: 'Basic dGhlZHJpdmVyaXM6eGVudXByZQ=='
Any ideea why $r->user() fails?
Thanks
I suspect that $r->user() is only set when mod_perl2 does the authentication, not when apache does it.
Try adding:
my ($res, $sent_pw) = $r->get_basic_auth_pw;
above the call to $r->user(). This might trigger the module to decode the Authorization header.
or, you could manually base64 dcode the Authorization header:
my $auth = $r->headers_in->get('Authorization');
my $username = (split(/:/,APR::Base64::decode((split(/ /,$auth))[1])))[0];