According the documentation (https://docs.kanboard.org/en/latest/admin_guide/reverse_proxy_authentication.html), i try to configure a simple authentication using the REVERSE_PROXY_USER_HEADER parameter.
For that, i set the parameters (data/config.php) like that !
define('REVERSE_PROXY_AUTH', true);
define('REVERSE_PROXY_USER_HEADER', 'REMOTE_USER');
define('REVERSE_PROXY_DEFAULT_ADMIN', 'admin');
define('REVERSE_PROXY_DEFAULT_DOMAIN', 'my-domain.fr');
I also change the apache2 log format for display my HTTP headers and i can see my 'user-name' in the corresponding log.
My HTTP request is this one :
Host: kbsso.my-domain.fr
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Cookie: KB_SID=g6re22ivihojnle991idmo4vhh; KB_RM=4c14de632e17976bc894b9dd0f273c0415d0fef620b62b00bc8e782084775a97%7Cf47e8c6b8ab3721c60dd32fbc4ed129fedbeafc388ff66b3c9933e28c08d
Upgrade-Insecure-Requests: 1
REMOTE_USER: ex.valere.viandier
Pragma: no-cache
Cache-Control: no-cache
So, my problem is...
When REVERSE_PROXY_AUTH is set to true, the controller show me the login screen but if i try to loggin, i receive an "Access denied" HTML page.
When REVERSE_PROXY_AUTH is set to false, the controller show me the login screen and, using the same user account, i can access to kanboard.
The documentation say :
Your reverse proxy authenticates the user and send the username through a HTTP header.
Kanboard retrieve the username from the request
The user is created automatically if necessary
Open a new Kanboard session without any prompt assuming it’s valid
I try with existing and non-existing user but i have the same problem.
I try with v1.2.5, v1.2.8 but no way...
Do you know an issue ?
Thx a lot
Valère
Related
I'm working with a SSO Saml authentication flow which looks as follows:
User sends SAMLRequest
User is redirected to IdP login page
User submits login details
IdP authenticates and redirects to my consumer assertion processing page
Access token extracted and submitted for a token to interact with API
I'm stuck on step 5. In fiddler, I can see the request header being sent with the required SAMLResponse posted, but it does not show in $_POST, $_GET and I've tried file_get_contents('php://input'). The response is the result of a 301 redirect.
The incoming header request with the required SAMLResponse redirected (301) to my assertion consumer page looks as follows. I can't figure out how to extract the posted parameter SAMLResponse?
POST http://localhost/xxxxxxxxxxx
Host: localhost
Connection: keep-alive
Content-Length: 7710
Cache-Control: max-age=0
Origin: null
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: optimizelyEndUserId=oeu1463724346007r0.9674156716176872; ajs_anonymous_id=%22c336991a-286a-4278-8cb2-3d00d784f376%22; optimizelySegments=%7B%225943211328%22%3A%22direct%22%2C%225934960299%22%3A%22false%22%2C%225952160221%22%3A%22gc%22%7D; optimizelyBuckets=%7B%7D; ajs_user_id=null; ajs_group_id=null; _ga=GA1.1.1336717339.1458634274; PHPSESSID=imtffdda2a6g576rtd0vpb8ro2
SAMLResponse=xxxxxxxxxxxxxxxx
I've been scanning the web for a week but have not found a solution. Thanks in advance for any help.
It turns out I was missing a trailing / on my consumer assertion url which of course meant the server was redirecting to index.php resulting in the loss of post vabriables.
I have some trouble getting a response from the new Bigcommerce api, not sure what I'm doing wrong.
Followed the instructions to get an Oauth token upon app install here:
developer.bigcommerce.com/apps/callback
The token is stored and used to make this request:
https://api.bigcommerce.com/stores/{store hash}/v2/time
According to developer.bigcommerce.com/api/authentication:
I've added X-Auth-Client and X-Auth-Token respectively as the app client ID and Oauth token.
The server is just returning "0 NO RESPONSE" and I'm not sure what's wrong. It does return unauthorized if I remove one of the headers though.
Does anyone have an idea on this? Thank you.
--
I'm using the Advanced Rest Client app from chrome to test for responses. Basically calling my store's URL api.bigcommerce.com/stores/3t984h/v2/time as a GET request and passing X-Auth-Client and X-Auth-Token headers.
Request headers
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
X-Auth-Client: p1r37bt131z86675nofv9xmhietoe4t
X-Auth-Token: kzm1q2w8h11dfkgbxhg3j0i8amac86g
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en,zh;q=0.8,zh-TW;q=0.6,ko;q=0.4,en-GB;q=0.2,en-US;q=0.2
Finally got it. It was a spec issue which wasn't that obvious (to me at least).
According to this (https://developer.bigcommerce.com/api/headers)
I needed to add
Content-Type: application/json
Accept: application/json
to the request header for it go thru.
I have a SWF file which allows a user to upload files on my website. That SWF sends a POST request to upload.php on my server, thus uploading the file.
But before it does so, at upload.php I wanna make sure that the person who is doing this is signed in. For this currently, I check the SID cookie value sent in the request headers and check an entry against that SID value in my database (i store sessions in database). I works well for chrome but fails in firefox as it doesn't send any cookie headers when request is generated by the SWF.
How should I go about it. Thanks for help.
Headers sent in Chrome
Content-Length: 355894
Origin: http://localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52
Content-Type: multipart/form-data; boundary=----------ei4Ij5ae0ae0ei4Ef1Ef1KM7GI3Ef1
Accept: */*
Referer: http://localhost/home Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: PHPSSID = 238e320eewbjdbew923e092ejhwbjhwebd
Headers sent in FireFox
Accept: text/*
Content-Type: multipart/form-data; boundary=----------GI3Ef1Ef1ae0GI3cH2Ef1Ef1cH2KM7
User-Agent: Shockwave Flash
Host: localhost
Content-Length: 355894
Connection: Keep-Alive
Cache-Control: no-cache
It's a feature of Chrome, but not a Bug of FireFox. Uploading SWF's must explictly send browser cookies. Look at FancyUpload starting from version 3.0.
Also note, PHP with suhosin can remove session variables if User-Agent header is not equal to the browsers. This called 'Session Fixtion'. So Uploading SWF's must send browsers User-Agent during requests too (or just disable suhosin patch).
I have a very strange problem.
The blog has a permalink structure /%category%/%title%/. Everything works fine for posts but when accessing pages by directly typing their URL, I get 404. I noticed this when checking the Google Webmasters Tools. The pages open fine when clicking on their link within the site.
The last thing I should mention is that the titles contain some non Latin characters but they are properly encoded.
Does WordPress check the referrer header and makes some decisions based on its value?
Look at the headers that Firefox sends when accessing the pade directly and it returns 404 and when clicking on internal link:
Host localhost:8088
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip, deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection keep-alive
Host localhost:8088
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip, deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection keep-alive
Referer http://localhost:8088/dani/
The only difference is the referer header. Very strange.
The problem turned out to be not in the referer header but in the casing of the utf-8 url parts. The internal links are bult with lower-case letters as:
http://localhost:8088/dani/%d0%b1%d0%bb%d0%be%d0%b3/
and the page titles have the same look. But when typing a URL in a browser, it encodes the string with upper-case letters as:
http://localhost:8088/dani/%D0%B1%D0%BB%D0%BE%D0%B3/
which doesn't match the title of the page.
I was trying to login to a site using the PHP Curl library. Even though i have ben successfully logged in, i cant seem to access any other pages beyond the login page. Now i know there could be some issue with cookies but trust me, ive tried all possible combinations with COOKIEJAR and COOKIEFILE.
I needed some help with analyzing this set of LiveHTTPHeaders info. Im worried about the post fields- particularly the Login.x and the Login.y. They seem to change on every login. Could that be an issue? How do i figure out the way a random integer is being assigned to this value? Also, are more than 1 cookies being added? If so, how do i incorporate that into curl? Do i use one COOKIEJAR, multiple or name number of cookies in a single statement..
Ive pasted the Headers below-
http://amizone.net/Amizone/default.aspx
POST /Amizone/default.aspx HTTP/1.1
Host: amizone.net
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://amizone.net/
Cookie: ASPSESSIONIDSSBCDQAQ=FJHPMILBALMDGIFEOOOBNFHI
Content-Type: application/x-www-form-urlencoded
Content-Length: 55
username=1596681&password=CENSORED&Login.x=14&Login.y=15
I will only post the cURL code if needed.
LiveHTTPHeaders info for HOME PAGE:
GET /amizone/default.aspx HTTP/1.1
Host: amizone.net
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
LiveHTTPHeaders info for LOGIN: ** Shown on top. No changes.
LiveHTTPHeaders info for ANY PAGE ACCESS AFTER LOGIN--
GET /amizone/WebForms/TimeTable/StudentTimeTableForWeek.aspx HTTP/1.1
Host: amizone.net
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://amizone.net/amizone/WebForms/Home.aspx
Cookie: ASP.NET_SessionId=hn5mfsre0y3b1l45nxlgzr55; UserId=127953D3849DEF71FB6CF9F55DD3BBADE48E686D24ADC87923FB6C60077ECC0362AB0C5A9C4DF194461C348DBAE6FEC861827F886FE2C17EA79155500CA4FC04EE897B7658A59DA2F286F2436F6EDD07BE2DD7DD829798F4C81ABAEFEE400B3A71078A74BF1C169BF1DA2865CC9E5968FF26ED7D; countrytabs=0; countrytabsRT=0; countrytabsRB=0
***Notice how multiple cookies are sent in this case (i think). How should my cookiejar and cookiefile commands change?
When recording a session it is important that you first flush all cookies and then make sure you note when cookies are set by the server.
Very often, the required cookies are set in the login page or another page that the browser loads first, and then when you POST to the particular URL the previously set cookies must be passed on.
So, the attached trace is insufficient.
This cURL code has been sufficient for me in the past to maintain login sessions by storing cookies:
$ch = curl_init('https://somesecureurl.com/login/account');
curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_ENCODING, 'gzip, deflate');
curl_setopt($ch, CURLOPT_COOKIEFILE, '/tmp/hmcookies.txt'); // cookies in this file are sent by curl with the request
curl_setopt($ch, CURLOPT_COOKIEJAR, '/tmp/hmcookies.txt'); // upon completing request, curl saves/updates any cookies in this file
$data = curl_exec($ch);
Other things to ensure, the cookiejar file is writable by the webserver, or it has the permission to create the file.
As also stated by Daniel, some sites may require that you first visit a login page to get some initial cookies set, and then post the login form. So your requests may go:
Request login page
Post to login form
Try to access protected page