Re: How to Externally Access PHP Application that has Internal Links to Itself
Dear Aleks, As you advised, in the file ../Product1/interface/globals.php, we (a) Reviewed Line 137/138. This takes the value from Line 67/68. (b) Conducted two tests. Here are the results. We would appreciate any vector to solve this external access via HAProxy issue. TEST CASE 1: With the original product1 code, we are able to access it within company’s internal network via local DNS. But we cannot access the product externally through HAProxy. In logs, the prefix /product1 gets deleted after a few lines (see line#4 in logs below) in internal hyperlinks of the product. Output on page = /interface TEST CASE 2: When we manually input the path as below, we are able to access the product externally through HAProxy. But we cannot access it within company’s internal network via local DNS. In logs below, the prefix /Product1 appears in internal hyperlinks of the product. Line 67:$webserver_root = "/usr/local/Product1"; Line 68:$web_root = "/Product1"; Output on page = /product1/interface +++ HAProxy configuration +++ http-request set-header Host reqirep ^([^\ ]*)\ /Product1/?([^\ ]*)\ (.*)$ \1\ /\2\ \3 acl hdr_location res.hdr(Location) -m found rspirep ^Location:\ (https?://)(Product1).vm0.internal.domain(:[0-9]+)?(/.*)?(.*) Location:\/\2\3\4 if hdr_location #rspirep ^Location:\ (https?://Product1.vm0.internal.domain(:[0-9]+)?)?(/.*) Location:\ /Product1\3 if hdr_location #cookie acl hdr_set_cookie_dom res.hdr(Set-cookie) -m sub Domain= Product1.vm0.internal.domain rspirep ^(Set-Cookie:.*)\ Domain=Product1.vm0.internal.domain(.*) \1\ Domain=\2 if hdr_set_cookie_dom acl hdr_set_cookie_path res.hdr(Set-cookie) -m sub Path= rspirep ^(Set-Cookie:.*)\ Path=(.*) \1\ Path=/Product1\2 if hdr_set_cookie_path server Product1.vm0 Product1.vm0.internal.domain:80 cookie p1-p check +++ Info.Log CASE 1: With the original product code, we are able to access it within company’s internal network via local DNS. But we cannot access the product externally through HAProxy. Oct 30 18:25:42 localhost haproxy[18120]: 192.168.100.153 - - [30/Oct/2015:23:25:42 +] "GET /Product1/interface/login/login_frame.php?site=default HTTP/1.1" 200 1159 "" "" 62551 160 "webapps-frontend~" "subdomain_p1-backend" "Product1.vm0" 28 0 1 13 42 1 1 0 1 0 0 0 "" "" Oct 30 18:25:42 localhost haproxy[18120]: 192.168.100.153 - - [30/Oct/2015:23:25:42 +] "GET /Product1/interface/login/login_frame.php?site=default HTTP/1.1" 200 1159 "" "" 62551 160 "webapps-frontend~" "subdomain_p1-backend" "Product1.vm0" 28 0 1 13 42 1 1 0 1 0 0 0 "" "" Oct 30 18:25:42 localhost haproxy[18120]: 192.168.100.153 - - [30/Oct/2015:23:25:42 +] "GET /Product1/interface/themes/login.css HTTP/1.1" 304 129 "" "" 62551 202 "webapps-frontend~" "subdomain_p1-backend" "Product1.vm0" 10 0 1 0 11 1 1 0 1 0 0 0 "" "" #4: Oct 30 18:25:42 localhost haproxy[18120]: 192.168.100.153 - - [30/Oct/2015:23:25:42 +] "GET /Product1/interface/themes/login.css HTTP/1.1" 304 129 "" "" 62551 202 "webapps-frontend~" "subdomain_p1-backend" "Product1.vm0" 10 0 1 0 11 1 1 0 1 0 0 0 "" "" #5: Oct 30 18:25:42 localhost haproxy[18120]: 192.168.100.153 - - [30/Oct/2015:23:25:42 +] "GET /interface/login/filler.php HTTP/1.1" 503 213 "" "" 62551 214 "webapps-frontend~" "webapps-backend" "" 2 -1 -1 -1 2 SC-- 2 2 0 0 0 0 0 "" "" Oct 30 18:25:42 localhost haproxy[18120]: 192.168.100.153 - - [30/Oct/2015:23:25:42 +] "GET /interface/login/filler.php HTTP/1.1" 503 213 "" "" 62551 214 "webapps-frontend~" "webapps-backend" "" 2 -1 -1 -1 2 SC-- 2 2 0 0 0 0 0 "" "" Oct 30 18:25:42 localhost haproxy[18120]: 192.168.100.153 - - [30/Oct/2015:23:25:42 +] "GET /interface/login/login_title.php HTTP/1.1" 503 213 "" "" 62557 222 "webapps-frontend~" "webapps-backend" "" 4 -1 -1 -1 4 SC-- 3 3 0 0 0 0 0 "" "" Oct 30 18:25:42 localhost haproxy[18120]: 192.168.100.153 - - [30/Oct/2015:23:25:42 +] "GET /interface/login/login_title.php HTTP/1.1" 503 213 "" "" 62557 222 "webapps-frontend~" "webapps-backend" "" 4 -1 -1 -1 4 SC-- 3 3 0 0 0 0 0 "" "" - CASE 2: When we manually input the path, we are able to access the product externally through HAProxy. But we cannot access it within company’s internal network via local DNS. The prefix /Product1 appears in internal hyperlinks of the product1. Nov 4 13:07:30 localhost haproxy[5246]: 192.168.100.153 - - [04/Nov/2015:19:07:30 +] "GET /Product1/ HTTP/1.1" 302 235 "" "" 63715 211 "webapps-frontend~" "subdomain_p1-backend" "Product1.vm0" 35 0 0 1 36 1 1 0 1 0 0 0 "" "" Nov 4 13:07:30 localhost haproxy[5246]: 192.168.100.153 - - [04/Nov/2015:19:07:30 +] "GET /Product1/ HTTP/1.1" 302 235 "" "" 63715 211 "webapps-frontend~" "subdomain_p1-backend" "Product1.vm0" 35 0 0 1 36 1 1 0 1 0 0 0 "" "" Nov 4 13:07:30 localhost haproxy[5246]: 192.168.100.153 - -
[patch] Enable USE_CPU_AFFINITY by default on FreeBSD
Change is being used in pfSense and also was added to FreeBSD ports tree. Should I send a separate patch for 1.6 branch? Thanks 0001-Enable-USE_CPU_AFFINITY-by-default-on-FreeBSD.patch Description: Binary data -- Renato Botelho signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [patch] Enable USE_CPU_AFFINITY by default on FreeBSD
> On 04 Nov 2015, at 23:09, Renato Botelho wrote: > > Change is being used in pfSense and also was added to FreeBSD ports tree. > > Should I send a separate patch for 1.6 branch? > > Thanks > > <0001-Enable-USE_CPU_AFFINITY-by-default-on-FreeBSD.patch> I would also add USE_GETADDRINFO by default, we use it unconditionally in FreeBSD ports tree too.
[PATCH] BUG/MINOR: acl: don't use record layer in req_ssl_ver
The initial record layer version in a SSL handshake may be set to TLSv1.0
or similar for compatibility reasons, this is allowed as per RFC5246
Appendix E.1 [1]. Some implementations are Openssl [2] and NSS [3].
A related issue has been fixed some time ago in commit 57d229747
("BUG/MINOR: acl: req_ssl_sni fails with SSLv3 record version").
Fix this by using the real client hello version instead of the record
layer version.
This was reported by Julien Vehent and analyzed by Cyril Bonté.
The initial patch is from Julien Vehent as well.
This should be backported to stable series, the req_ssl_ver keyword was
first introduced in 1.3.16.
[1] https://tools.ietf.org/html/rfc5246#appendix-E.1
[2]
https://github.com/openssl/openssl/commit/4a1cf50187659e60c5867ecbbc36e37b2605d2c3
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=774547
---
src/payload.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/payload.c b/src/payload.c
index ce9280c..5d9efa1 100644
--- a/src/payload.c
+++ b/src/payload.c
@@ -402,7 +402,7 @@ smp_fetch_req_ssl_ver(const struct arg *args, struct sample
*smp, const char *kw
if (bleft < 5)
goto too_short;
- version = (data[1] << 16) + data[2]; /* version: major, minor */
+ version = (data[9] << 16) + data[10]; /* client hello version:
major, minor */
msg_len = (data[3] << 8) + data[4]; /* record length */
/* format introduced with SSLv3 */
--
1.9.1
20% discount !super professional HD body camera and CCTV camera
DearSirorMadam=, Hopethingsarewellwithyou.= Bytheway,Wesupply oneofours=uperprofessional 3Gnetworkcameras whichsellespeciallyw=ellforyourreference.Everymonth ,weallexportover5000pcs=toUSA and Europe.,Ifyouarewrokinginthefieldofit,w=elcomeyourinquiries ,thanks. OEM,ODMareavailable. ModelNo.:SM-NC336GWelookforwardtohearingfromyou. BestRegardsPollyContactUS:Company Name:SmartShineTechnologyCo;=Ltd.Address:2Bui=lding,Tongle IndustryPark ,NanshanRoad,Nanshan Ind=ustry,Shenzhen,China.Tel:0086=13528871-267Fax:008675526=187082Email: po=llyyu...@hotmail.com &n=bsp; i...@szsmartshine.com Website=: www.szsmartshine.com &=nbsp;
How to protect the TV set and kiosk display with the flight case
Hi There, If you know how violent the courier is, then you wont refuse the flight case to protect your TV set or kiosk display these fragile. Yes, our factory Arboocase located in China is the leading flight case manufacturer who can give you custom made flight case design and manufacturing. If you have the perplexity about this, let us know to find more packaging solutions. Best Regards Ellen Arboocase China www.arboocase.com
Re: [PATCH] BUG/MINOR: acl: don't use record layer in req_ssl_ver
Hi Lukas,
On Thu, Nov 05, 2015 at 12:00:50AM +0100, Lukas Tribus wrote:
> The initial record layer version in a SSL handshake may be set to TLSv1.0
> or similar for compatibility reasons, this is allowed as per RFC5246
> Appendix E.1 [1]. Some implementations are Openssl [2] and NSS [3].
>
> A related issue has been fixed some time ago in commit 57d229747
> ("BUG/MINOR: acl: req_ssl_sni fails with SSLv3 record version").
>
> Fix this by using the real client hello version instead of the record
> layer version.
>
> This was reported by Julien Vehent and analyzed by Cyril Bonté.
> The initial patch is from Julien Vehent as well.
>
> This should be backported to stable series, the req_ssl_ver keyword was
> first introduced in 1.3.16.
Thanks to all for this very detailed analysis, but this patch introduces a
bug :
> @@ -402,7 +402,7 @@ smp_fetch_req_ssl_ver(const struct arg *args, struct
> sample *smp, const char *kw
> if (bleft < 5)
> goto too_short;
>
> - version = (data[1] << 16) + data[2]; /* version: major, minor */
> + version = (data[9] << 16) + data[10]; /* client hello version:
> major, minor */
> msg_len = (data[3] << 8) + data[4]; /* record length */
See above ? we check for 5 bytes minimum because we didn't parse further
than data[4], and now we're reading data[10], so the test on bleft above
must be changed to bleft < 11.
Can someone please check if the other patch referenced above has the same
bug ?
Thanks,
Willy
Re: LUA, 'retry' failed requests
Hi, Now, because of you I have my own freebsd installed :). I can reproduced the segfault. I suppose that the OS other than Freebsd are impacted, but luckyly it not visible. I encounter an easy compilation error. So can you test the two attached patches. The first one fix the compilation issue, and the second one fix he segfault. Thierry On Mon, 2 Nov 2015 20:50:01 +0100 PiBa-NL wrote: > Op 2-11-2015 om 10:03 schreef Thierry FOURNIER: > > On Sat, 31 Oct 2015 21:22:14 +0100 > > PiBa-NL wrote: > > > >> Hi Thierry, haproxy-list, > > > > Hi Pieter, > Hi Thierry, > > > > > >> I've created another possibly interesting lua script, and it works :) > >> (mostly). (on my test machine..) > >> > >> When i visit the 192.168.0.120:9003 website i always see the 'Hello > >> World' page. So in that regard this is usable, it is left to the browser > >> to send the request again, not sure how safe this is in regard to > >> mutations being send twice. It should probably check for POST requests > >> and then just return the error without replacing it with a redirect.. > >> Not sure if that would catch all problem cases.. > >> > >> Ive created a lua service that counts how many requests are made, and > >> returns a error status every 5th request. > >> Second there is a lua response script that checks the status, and > >> replaces it by a redirect if it sees the faulty status 500. > >> This does currently result in the connection being closed and reopened > >> probably due to the txn.res:send().?. > >> > >> Though i am still struggling with what is and isn't supposed to be > >> possible. > >> For example the scripts below are running in 'mode http' and mostly just > >> changing 'headers'. > >> I expected to be able to simply read the status by calling > >> txn.f:status() but this always seems to result in 'null'. > >> Manually parsing the response buffer duplicate works but seems ugly.. > >> > >> txn.f:status() < it doesnt result in the actual status. > > > > This is a bug wich I reproduce. Can you try the attached patches ? > With the patches it works without my 'workaround', thanks. > > > >> txn.res:set() < if used in place of send() causes 30 second delay > > > > This function put data in the input part of the response buffer. This > > new data follows the HAProxy stream when the Lua script is finished. > > It is your case. > > > > I can't reproduce this behaviour, I suppose that its because I work > > locally, and I'm not impacted by the network latency. > Even when i bind everything to 0.0.0.0 and use 127.0.0.1 to query the > 9003 port it still waits for the timeout to strike.. > I'm not sure why it doesn't happen in your setup.. Of course i'm running > on FreeBSD, but i don't expect that to affect this.. > > > > > >> txn.done() < dumps core. (im not sure when ever to call it? the script > >> below seems to match the description that this function has.?.) > > > > I can't reproduce too, for the same reasons, I guess. > Please note that both set() and done() need to be uncommented for the > dump to happen, with the 5th request. > > Not sure if it helps, but backtrace of the dump below (would 'bt full' > be more usefull?): > (gdb) bt > #0 0x000801a76bb5 in memmove () from /lib/libc.so.7 > #1 0x00417523 in buffer_insert_line2 (b=0x8024a, > pos=0x8024a0035 "\r\n\ncontent-type: text/plain\r\ncontent-length: > 394\r\n\r\nError 5\r\nversion\t\n[HTTP/1.1]\t\nf\t\n 0\t\n > [userdata: 0x802683a68]\t\nsc\t\n 0\t\n [userdata: > 0x802683be8]\t\nc\t\n 0\t\n [userdata: 0x802683b68]\t\nheader"..., > str=0x58c695 "Connection: keep-alive", len=22) at src/buffer.c:126 > #2 0x0047b3a5 in http_header_add_tail2 (msg=0x8024bb290, > hdr_idx=0x8024bb280, text=0x58c695 "Connection: keep-alive", len=22) > at src/proto_http.c:595 > #3 0x0047f943 in http_change_connection_header > (txn=0x8024bb280, msg=0x8024bb290, wanted=8388608) at src/proto_http.c:2079 > #4 0x004900fd in http_process_res_common (s=0x802485600, > rep=0x802485650, an_bit=262144, px=0x8024de000) at src/proto_http.c:6882 > #5 0x004d6c90 in process_stream (t=0x8024ab710) at > src/stream.c:1918 > #6 0x00420588 in process_runnable_tasks () at src/task.c:238 > #7 0x0040ce0e in run_poll_loop () at src/haproxy.c:1559 > #8 0x0040dcb2 in main (argc=4, argv=0x7fffeb00) at > src/haproxy.c:1912 > > > > >> Am i trying to do it wrong? > >> > >> p.s. Is 'health checking' using lua possible? The redis example looks > >> like a health 'ping'.. It could possibly be much much more flexible then > >> the tcp-check send / tcp-check expect routines.. > > > > It is not possible. You can write a task which do something (like an > > http request) and reuse the result in the request processing Lua code, > > but this task cannot set the status of the server. > The doc does say for core.register_task(func) "For example this type of > tasks can be executed to perform complex hea
RE: [PATCH] BUG/MINOR: acl: don't use record layer in req_ssl_ver
>> @@ -402,7 +402,7 @@ smp_fetch_req_ssl_ver(const struct arg *args, struct >> sample *smp, const char *kw >> if (bleft < 5) >> goto too_short; >> >> - version = (data[1] << 16) + data[2]; /* version: major, minor */ >> + version = (data[9] << 16) + data[10]; /* client hello version: major, >> minor */ >> msg_len = (data[3] << 8) + data[4]; /* record length */ > > See above ? we check for 5 bytes minimum because we didn't parse further > than data[4], and now we're reading data[10], so the test on bleft above > must be changed to bleft < 11. > > Can someone please check if the other patch referenced above has the same > bug? Ouch, here's the original patch: http://marc.info/?l=haproxy&m=144431273015849&w=2 It does indeed bump this check to 11 bytes. Also, there is a third change in that path, where it touches bleft and data values (bleft -= 11; data += 11;) some lines below. The original patch does not work, at this point I'm not quite sure why. Both the the first and the third change in the original patch are necessary, is that correct? Thanks and sorry for the near-miss, Lukas
