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];
Related
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.
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?
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.
I have a working spring-mvc application with rest services and some rest-assured tests which are fine :
#Test
public void createFoobarFromScratchReturns201(){
expect().statusCode(201).given()
.queryParam("foo", generateFoo())
.queryParam("bar", generateBar())
.when().post("/foo/bar/");
}
=> OK
Then I implemented a digest authentication. Everything is working well, now I have to log in to use my services :
curl http://localhost:8089/foo/bar
=> HTTP ERROR 401, Full authentication is required to access this resource
curl http://localhost:8089/foo/bar --digest -u user_test:password
=> HTTP 201, CREATED
But when I try to upgrade my tests with the most obvious function, I still have a 401 error :
#Test
public void createFoobarFromScratchReturns201(){
expect().statusCode(201).given()
.auth().digest("user_test", "password") // Digest added here
.queryParam("foo", generateFoo())
.queryParam("bar", generateBar())
.when().post("/foo/bar/");
}
=> Expected status code <201> doesn't match actual status code <401>
I found some clues with the preemptive() function, but it seems to be only implemented for basic :
// Returns an AuthenticatedScheme and stores it into the general configuration
RestAssured.authentication = preemptive().basic("user_test", "password");
// Try a similar thing, but it didn't work :
RestAssured.authentication = RestAssured.digest("user_test", "password");
Currently, I am trying to achieve two things :
I need to upgrade a couple of my tests to support digest
I need to amend the #Before of the rest of my tests suites (whose are not related to auth issues), to be already logged in.
Any ideas or documentation ?
Try enabling support for cookies in the HTTP client embedded inside Rest Assured with:
RestAssuredConfig config = new RestAssuredConfig().httpClient(new HttpClientConfig().setParam(ClientPNames.COOKIE_POLICY, CookiePolicy.BEST_MATCH));
expect().statusCode(201).given()
.auth().digest("user_test", "password") // Digest added here
.config(config)
.queryParam("foo", generateFoo())
.queryParam("bar", generateBar())
.when().post("/foo/bar/");
The HTTP client (and therefore Rest Assured) supports digest authentication and the configuration of RestAssured using the digest method works well.
I'm having trouble downloading an mp4 file using WWW::Mechanize. A normal browser, like Firefox, can do the file fetching without any problem with or without Javascript enabled. So it seems to me Javascript, the usual suspect, hasn't played a real part in my problem. I've also added in my script the same headers as sent by Firefox to the file server when doing the fetch so that the server may see Mechanize as a normal browser, but the problem persists. And Win32::IE::Mechanize can also do the job well but why Mechanize can't?
Any ideas? Thanks in advance :)
Here's a my script:
use strict;
use warnings;
use WWW::Mechanize;
my $browser = WWW::Mechanize->new();
$browser->cookie_jar(HTTP::Cookies->new());
$browser->add_header('User-Agent' => 'Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.1.11) Gecko/20100701 Firefox/3.5.11');
$browser->add_header('Accept' => 'text/xml,application/xml,application/xhtml+xml;q=0.9,*/*;q=0.8');
$browser->add_header('Accept-Language' => 'zh-cn,zh;q=0.5');
$browser->add_header('Accept-Encoding' => 'gzip,deflate');
$browser->add_header('Accept-Charset' => 'GB2312,utf-8;q=0.7,*;q=0.7');
$browser->add_header('Keep-Alive' => 300);
$browser->add_header('Connection' => 'keep-alive');
my $url = 'http://119.167.217.206:19765/ppvaplaybyopen?url=http://119.167.217.206/%d3%e9%c0%d6%b0%d9%b7%d6%b0%d9-100803-%d0%a1%d6%ed%bd%dc%c2%d7%b7%d6%d7%e9%d0%e3%c7%f2%bc%bc.mp4/segno=0%26&rid=A8F1F5DFEB1B11F1D90B40AD1BB75D69&filelength=21293994&blocksize=2097152&blocknum=11&blockmd5=E210862B3F92935D0883E00AA2A38F08#D793599727C6DA4ACDB1CBF2235004AC#D5E9C9245C9A1BB63BC5EDA862A32604#51B5FDF91356B2B4E943EF72648EB0AD#6F2400488B04EBF66A60336B795EA142#8E51B8DCF87A7A02B84A2CAA5FFCA3CF#89080D683268481694DBA6D1E22A2EFF#8F56225C76854A434385A09C319BF9C3#9AB0A3F199183F479F8887D1C3341B1B#845FE0D711086CC2D086546CD26B35C1#9D93A9BE1D2EDE216AA9EBF26BF414BE';
$browser->get($url);
I'm receiving the following error message:
Error GETing http://119.167.217.206:19765/ppvaplaybyopen?url=http://119.167.217.206/%d3%e9%c0%d6%b0%d9%b7%d6%b0%d9-100803-%d0%a1%d6%ed%bd%dc%c2%d7%b7%d6%d7%e9%d
0%e3%c7%f2%bc%bc.mp4/segno=0%26&rid=A8F1F5DFEB1B11F1D90B40AD1BB75D69&filelength=21293994&blocksize=2097152&blocknum=11&blockmd5=E210862B3F92935D0883E00AA2A38F08
#D793599727C6DA4ACDB1CBF2235004AC#D5E9C9245C9A1BB63BC5EDA862A32604#51B5FDF91356B2B4E943EF72648EB0AD#6F2400488B04EBF66A60336B795EA142#8E51B8DCF87A7A02B84A2CAA5FF
CA3CF#89080D683268481694DBA6D1E22A2EFF#8F56225C76854A434385A09C319BF9C3#9AB0A3F199183F479F8887D1C3341B1B#845FE0D711086CC2D086546CD26B35C1#9D93A9BE1D2EDE216AA9EB
F26BF414BE: Internal Server Error at E:\pp2.pl line 17
I get same "Internal Server Error" when I go to same URL. Possible causes:
You didn't set referer correctly.
You have some authentication, which you do in browser, or any other data stored in cookie.
In general, opening URL in other browser, is a good way to check such things. "Live http headers" Firefox extension is a good way to check for such things.
another possibility the "Internal Server Error" error is your connection was reset