Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Witam.
Nie jestem do końca przekonany czy to powinno być w tym dziale czy "Sieciach"... w razie czego można przenieść.
Skrobię sobie testową stronkę w .NET+Mono z wykorzystaniem framework'a NancyFX:
http://nancyfx.org/
Chcę to wystawić potem na Raspberry PI, na razie wszystko w miarę działa i choć w bólach, to jest postęp, aczkolwiek ze względu na to że stronka jest pisana głownie na Windos to wybrałem tryb self-host jako najbardziej optymalną formę rozwiązania multisystemowego (czyli generuje się aplikacja konsolowa która sama w sobie jest małym serwerkiem HTML). Wszystko OK, tylko teraz problem: bez SSL (a raczej bez szyfrowania) nie chcę tego używać (zaimplementowałem sobie autentykację, która jak wiadomo bez szyfrowania guzik daje bo każdy nasz token przełapie), na Windos udało mi się bez większych problemów dodać certyfikat (wygenerowany poprzez OpenSSL na Ubuntu) oraz "przekierować" go na konkretny port, za pomocą netsh:
netsh http add sslcert ipport=0.0.0.0:1234 certhash=0000000000003ed9cd0c315bbb6dc1c08da5e6 appid={00112233-4455-6677-8899-AABBCCDDEEFF}
Dzięki powyższej komendzie, wystarczy że nakieruję Nancy na https://localhost:1234 i już mam SSL i szyfrowanie, pytanie jak coś takiego zrobić na Linuksie? Korzystając z tego:
http://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate
Udało mi się dodać wcześniej wygenerowany certyfikat i sprawić aby Ubuntu go widziało - ale co dalej? Jak zrobić takie "przekierowanie" konkretnego portu na konkretny certyfikat - jak to jest na Windos?
Z góry dzięki za info.
Pozdrawiam.
Offline
Weź lepiej posadź to Nancy na Nginxie, a tam z certyfikatami i autoryzacją pkcs12 na Vhostach nie ma problemu.
https://github.com/NancyFx/Nancy/wiki/Hosting-Nancy-with-Nginx-on-Ubuntu
Ostatnio edytowany przez Jacekalex (2015-04-12 21:17:04)
Offline
1847
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:15:53)
Offline
@Jacekalex:
Właśnie tego bym chciał uniknąć :/ wiem że się da ale znowu muszę stawiać nginx na Windos i przerabiać na to kod (niby nie za dużo ale...), wychodzę z założenia że skoro w Windos się da to i tutaj powinno...?
@uzytkownikubunt:
Obczaję ten stunnel...
Pod Windos wyglądało to tak że po dodaniu certa i komendzie netsh wszystko działało od strzała, o ile dobrze rozumiem to w przypadku SelfHostingu, system musi być skonfigurowany tak aby dopuszczał SSL na konkretnym porcie dla wybranego certyfikatu - tyle.
Co do OpenSSH - to ma być wystawione jako stronka... da się pogodzić OpenSSH z przeglądarką? O tym nie słyszałem...
Offline
1848
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:15:54)
Offline
Nginx na Windows stawiać nie musisz, po prostu najpierw sobie wybierz system, a potem dopasuj do niego resztę zabawek.
Przy okazji, czy naprawdę stronkę do netu chcesz wystawiać na systemie Windows, i do tego wystawiać aplikację mono na jakimś wbudowanym chooojwiejakim serwerze www?
Skonsultowałeś sprawę z ładną psycholożką?
Apache, Lightppd, Nginx, LiteSpeed, to są serwery znane pod względem wydajności i bezpieczeństwa.
A w przypadku tego Mono to tak, jakbyś stronę www stawiał na simple-http-server z Pythona albo podobnym skrypcie Perla.
Oczywiście, że się da, ale pokaż mi wariata, który by ryzykował z takim rozwiązaniem w jakimś poważnym projekcie.
Serwer WWW musi być gotowy na rożne roboty i łomoty, jakie prędzej czy później dostanie z netu, a serwerek wbudowany w Mono, jak wygląda jego odporność i twardość? ;)
Jak wytrzymuje duże obciążenie?
Na Windows też raczej masz Apacha albo Microsoft IIS (schowanego za ISA-server).
PS.
Jak koniecznie chcesz się w Linuxie bawić w "hakera-partyzanta" to ja bym radził to:
http://www.superscript.com/ucspi-ssl/
ale jednakowej konfiguracji w Windows i Linux i tak nie osiągniesz, to po prostu są troszkę inne systemy, o innej architekturze.
PS2:
Jeżeli w Windowsie można tak po prostu na porcie, to znaczy, że masz tam coś w typie Inetd/Xinetd, w Linuxie też można takie demony postawić, ale lepiej i bezpieczniej wyjdziesz na zwykłym serwerku WWW, najlżejszy z tych "poważnych" jest chyba Lighttpd.
Pozdro
Ostatnio edytowany przez Jacekalex (2015-04-12 22:05:48)
Offline
@uzytkownikubunt:
Na razie powiedzmy że to ma być prototyp możliwości mono + mała apka którą od dawna chcę napisać, a przy okazji właśnie chcę w końcu liznąc nieco konfiguracji SSL itd. ;] ale dzięki za info, nie wiedziałem że takie cuda się da z SSH robić, wracając do sprawy - na pierwszy rzut oka ten stunnel wydaje się być tym czego potrzebuję, a czy jest tak na pewno wyjdzie w praniu, dzięki za cynk :)
@Jacekalex:
Cały sens tego projektu jest taki:
1. Sprawdzić czy da się napisać aplikację (webową) która działa zarówno na Windos jak i na Linuksie - a dokładniej, gdzie na Windos się ją tworzy, a na Linuchu wystawia (cytując swojego pierwszego posta "[b]Chcę to wystawić potem na Raspberry PI[/b]" - fakt że RPI 2 ponoć jakiegoś Windosa obsługuje ale mnie to nie obchodzi).
2. Sprawdzić jak dobrze działają zastępniki komponentów M$ - np. zamiast Sql Server jest PostgreSQL.
3. Sprawdzić czy da się to wystawić na RPI i czy RPI da radę jakoś to uciągnąć.
4. Przy okazji liznąć nieco informacji o SSL, CORS, Owin, AngularJS i paru innych bzdetach.
Nie mam zamiaru wystawiać tego na Windos (choćbym chciał to szkoda kasy na serwer z tym cholerstwem), poza środowiskiem testowym - inna sprawa że widzę codziennie serwery na Windos w pracy i jakoś włamu na razie nie było (a tam gdzie pracuję, jakby włam był to by pół polski szybciutko o tym usłyszało ;] ), więc bez przesady...
Jak pisałem - [b]na razie[/b] obczajam SelfHosting, bo ostatnio robi się na to jakiś boom - zapoczątkowany w sumie przez NodeJS którego można tak wystawiać, teraz widzę że M$ dodał taką opcję do Owin'a, widać ludzie nie chcą zależeć od konkretnego serwera - moje poglądy na ten temat nie mają znaczenia, jak swego czasu zapytałem odnośnie kwestii bezpieczeństwa Self v serwer na Stackoverflow to moje pytanie zostało ostro zminusowane i wywalone bo "There should be no securitty difference between selfhosted application and application hosted on serwer.", well kim że ja jestem żeby się sprzeczać ze specami SO... choć swoją drogą, jakie są realne zabezpieczenia oferowane przez serwer typu Apache w porównaniu do self hosta? Możesz coś wymienić? W przypadku IIS jedyne co mi do łba przyszło (poza potencjalnym Load-Balancingiem) to teoretyczna ochrona przed wyjściem ponad root path strony...
Jak to wygląda w praktyce?
Offline
jakie są realne zabezpieczenia oferowane przez serwer typu Apache w porównaniu do self hosta[/quote]
Co ma Apache czy Nginx?
To, co sobie włączysz ;)
Filtrowanie GET i POST regexem?
Kontrola dostępu?
Limity liczby połączeń i maks transferu per/ip/mask?
Mod_security?
Autoryzacja http hasłem/kluczem x509/p12?
Mod Evasive (to w Apache).
Skrypty CGI - Apache i Lighttpd, Nginx nie ma moda do CGI.
Vhosty?
Przede wszystkim dosyć stabilne, bezpieczne i zweryfikowane w necie miliony razy środowisko serwera WWW, czego o wypocinach Mono ciężko powiedzieć, o jakichś wynalazkach w typie JQuery czy NodeJS nie wspominając w ogóle.bo ostatnio robi się na to jakiś boom - zapoczątkowany w sumie przez NodeJS którego można tak wystawiać, teraz widzę że M$ dodał taką opcję do Owin'a, widać ludzie nie chcą zależeć od konkretnego serwera - moje poglądy na ten temat nie mają znaczenia, jak swego czasu zapytałem odnośnie kwestii bezpieczeństwa Self v serwer na ...[/quote]
Na każde cudo na początku jest wielki boooom, a potem zazwyczaj jeszcze większy kac, kiedy to cudo pokaże, ile naprawdę jest warte z każdej możliwej strony.
Amber Gold, kredyty we frankach, już przeminęły, sraczka z wspaniałością JQuery i gotowych biliotek js, które strona includuje prosto z serwera np googleapis czy jakiejś innej chmury też mają tysiące fanboyów, ale już z samym JQuery była jedna wtopa, od której niektórych dupy zabolały.
Ku pamięci:
http://niebezpiecznik.pl/post/jquery-com-infekowalo-zlosliwym-oprogramowaniem/
http://niebezpiecznik.pl/post/jquery-dojechane-po-raz-drugi/Ostatnio edytowany przez Jacekalex (2015-04-12 23:26:05)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)Offline
@Jacekalex:
Ciekawe... wychodzi na to że Nancy/Owin czy NodeJS oferuje (poza vhost'ami i modami) praktycznie to samo co serwery... oczywiście z tym "ale" że trzeba sobie zaimplementować - fakt że średni pomysł, choć ostatnio dużo takich wydawało by się średnich pomysłów staje się standardem... na razie sprawdzę sobie selfhost, potem się zobaczy.
Amber Gold, kredyty we frankach, już przeminęły, sraczka z wspaniałością JQuery i gotowych biliotek js, które strona includuje prosto z serwera np googleapis czy jakiejś innej chmury też mają tysiące fanboyów, ale już z samym JQuery była jedna wtopa, od której niektórych dupy zabolały.[/quote]
Nie wina Jquery że wielu debili zamiast samemu siać biblioteką wcześniej pobrana woli zostawiać linki do CDN'ów bo niby szybsze, ja co kilka miesięcy/lat słyszę że coś jest najpierw super a potem "bee" bo <tutaj wstaw dowolny bzdet>, nauczyłem się mieć takie opinie generalnie w "miękkim zakończeniu kręgosłupa" ;] człowiek by oszalał jakby słuchał tych wszystkich "mundrych" - kilka lat temu było ASP/JSP potem jQuery i tylko jQuery, teraz słyszę AngularJS, albo Ember, albo Knockout a jQuery nie bo <tutaj znowu wstaw dowolny argument który zawsze się znajdzie> a już podnoszą się głosy że Angular to crap... IMHO szkoda sobie tym głowy zawracać, a używać tego co się chce.
Pozdrawiam.
Offline
Wiesz, dlaczego na Linuxie musisz stawiać serwer?
Windows ma wbudowanego demona podobnego do Inetd,
w Linuxie go domyślnie nie ma od wielu lat, można go zainstalować, dopiero Systemd ma podobnego demona wbudowanego.
To jest ta drobna różnica, między Vistowatymi Windowsami a Linuxem, który spełnia w miarę możliwości zasadę KISS (mama na myśli poszczególne usługi).
Użycie demona Inetd/Xinetd to jest proszenie się o kłopoty, bo to kolejna krowa, która z prawami roota wisi na wszystkich portach i stanowi kolejną potencjalną dziurę w systemie.
Pliki [b]/etc/hosts.{allow|deny}[/b] to właśnie spadek po domyślnym Inetd, który w ten sposób zapewniał "bezpieczeństwo sieci", zanim pojawił się Ipchains.
Ostatnio go widziałem w Debianie Etch chyba (o ile się nie mylę).
Obecnie jest w Debku jako [b]openbsd-inetd[/b] albo [b]xinetd[/b]
ale chyba na szczęście nic go nie wymaga w tej chwili.
Ale jak tego draństwa nie masz, to nie możesz tak samo jak w Windows powiesić tego Nancycośtam na porcie z certyfikatem, potrzebujesz jakiegoś serwerka www albo demona tcpd.
Coś za coś.
PS.
Includowanie bibliotek JS, to spadek po "małym transferze" i problem szybkiego wczytywania stron.
Czasem na niejednej stronie idioci includują liby o pojemności nawet 200 kb, czyli 3x tyle, co strona tytułowa Onetu.
Pozdro
Ostatnio edytowany przez Jacekalex (2015-04-13 10:11:24)
Offline
OK, przerobiłem swój projekt żeby korzystał z nginx... plik konfiguracyjny wygląda nastepująco:
server { listen 80; listen 443 ssl; ssl_certificate /home/james/sslCert2/server.crt; ssl_certificate_key /home/james/sslCert2/server.key; server_name localhost; root /home/james/nancywebpageroot/NancyWebPage.DPL.Services/bin/Debug/; location /Content/ { alias /home/james/nancywebpageroot/NancyWebPage.DPL.Services/bin/Debug/Content/; location ~* \.(jpg|jpeg|png|gif|ico|css|js|ttf)$ { expires 365d; } } location / { proxy_pass https://127.0.0.1:5555; } }
Jednakże problem jak był tak pozostaje - projekt jest ustawiony tak żeby na porcie 5555 wystawiał SSL - tyle że nginx zwraca 500 z tego co widzę z logów to on przekierowuje zapytanie do Nancy a tam nic się nie dzieje... bo nie widzi certyfikatu, normalne zapytania http bez ssl działają - podejrzewam że coś zmąciłem tylko nie wiem co...
Pozdrawiam.
Offline
Zmąciłeś jedną rzecz (chyba, nie znam tego Nancy*).
Jak SSL realizujesz na Nginxie, to do Nancy już idzie bez szyfrowania, bo Nginx działa jako proxy.
Więc ten Nancy nie ma okazji dowiedzieć się o cercie i szyfrowaniu,
bo po prostu nie uczestniczy w szyfrowanym połączeniu.
Żeby Nancy wiedziało o szyfrowaniu, musiałoby samo go obsługiwać, względnie możesz kombinować z przekazaniem zmiennych dotyczących szyfrowania z Nginxa do Nancy jako nagłówki http, ale to już chyba fantastyka, w ogóle nie wiem, czy wykonalne.
W każdym razie, jeśli Nginx zapewnia szyfrowanie (zapewnia?) to połączenie szyfrowane (jest?), tylko Nancy nic o tym nie wie.
W ogóle Mono jest bardzo "udane" pod każdym względem, lepiej zajmij się oryginalnym NET.
Jeśli Nancy samo szyfruje, to wyłącz ssl na Nginxie, zostaw samo proxy, bo dwóch szyfrowań na jednym połączeniu mieć nie możesz na pewno.
Przy okazji, serwery www często głupieją, jak mają
server_name localhost;
bo ta nazwa wskazuje na 127.0.0.1, co przy połączeniu "z zewnątrz" może dawać dosyć dziwne efekty.
Ostatnio edytowany przez Jacekalex (2015-04-14 00:36:40)
Offline
@Jacekalex:
No jeżeli tak to działa to rozumiem skąd problemy - nie wiem jak ludki z Nancy to obsługują na Windos, wiem tyle że tam musiałem dodać cert + komenda netsh którą podałem i potem uruchomienie hosta na danym porcie z SSL... podejrzewam że jest jakiś kanał komunikacyjny który odpytuje Windosowego daemona od SSL - a na Linuchu możliwe że jest założenie że SSL załatwia serwer tak jak to opisałeś bo na razie problem jest taki że Nancy samo w sobie działa tylko na czystym HTTP, a próba wejścia na HTTPS (jeszcze przed ustawieniem nginx'a ) nic nie zwraca... na Windos przed dodaniem przekierowania w netsh było identycznie.
W ogóle Mono jest bardzo "udane" pod każdym względem, lepiej zajmij się oryginalnym NET.[/quote]
A co ma piernik do wiatraka? Nancy nie ma nic wspólnego ani z .NET ani z Mono - jest to framework pisany na licencji MIT, który ma być z założenia przenośny - poza problemami z ustawieniem SSL, jak do tej pory jest, a stawiam że i ten problem jest do rozwiązania - dzisiaj sprawdzę po pracy to co podałeś i zobaczymy.
Pozdrawiam.
Offline
Tak, to było to - jak ustawiłem Nancy na http only, a https przez nginx to śmiga... ale trochę to do bani - bo tracę na tym kilka ważnych dla mnie funkcjonalności wbudowanych (co prawda do uzyskana własnym kodem...) - no i są dwa różne podejścia, jedno dla Linucha inne dla Windosa (mogę co prawda nginx tam zainstalować ale...), bee.
No nic, dzięki za pomoc, ważne że się da reszta to szczegóły :) wreszcie jakiś framework z C# bez wymogu posiadania Windosowego serwera :P
Pozdrawiam.
Offline
To przestaw się, (o ile coś takiego istnieje), na framework C/C++, i będziesz miał wymóg posiadania dowolnego serwera,choć może w odkurzaczu się nie uruchomi, ale w "tosterze" z NetBSD albo mikrofali z RPI na pewno. :D
[OT]
W ogóle, kiedy M$ miał 98% rynku, to rozumiałem tą szczerą miłość do C#, ale kiedy jego realny udział w rynku nie przekracza 48%, to już nie bardzo rozumiem tą miłość do C#, chyba że to jakiś "Syndrom Sztokholmski".
W tej chwili każdy program powinien być gotowy na łatwe portowanie go na różne systemy i architektury, od M$, poprzez Andka, Linuxa, MacOS, BSD aż np po QNX (ten i podobne też może niedługo wypłynąć na jakieś platformie, np BlackBerry jeszcze żyje).
C# jest od takiego wymogu najdalej, jak to tylko możliwe, ze wszystkich istniejących języków programowania.
[/OT]
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2015-04-14 18:01:07)
Offline
server { server_name test.domena.tld; listen 0.0.0.0:443; listen [::]:443; index index.html; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_pass https://test.domena.tld:8081/; access_log /var/log/nginx/proxy.access_log; error_log /var/log/nginx/proxy.error_log info; }
Połączenia SSL przechodzą elegancko, tylko nie da się na Apachu (schowanym za Nginxiem) włączyć autoryzacji PKCS12.
Włączenie w Apachu (Virtualhost) opcji:
SSLVerifyClient require
Powoduje, ze Nginx zwraca błąd 502 a w logu mam:
2015/04/17 17:37:12 [error] 29690#0: *5 SSL_do_handshake() failed (SSL: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:SSL alert number 40) while SSL handshaking to upstream, client: 127.0.0.1...
W każdym razie zwykłe połączenie SSL bez certy klienta idzie normalnie, protokołem TLSv1.2.
Może się przyda.
;)
Ostatnio edytowany przez Jacekalex (2015-04-17 18:25:41)
Offline
@Jacekalex:
Sorry że taki "ping" ale ostatnio inne sprawy mnie zaabsorbowały...
Co do tematu... nie do końca rozumiem co do mnie prawisz ;] na "serwerowaniu" znam się tyle co nic, ale...
nginx + apach razem do obsługi jednej prostej stronki ? Do tego na Raspberry PI? Możesz wyjaśnić jakoś tak bardziej łopatologicznie jaki to ma sens? Sam nginx to za mało czy co? U mnie zdaje się działać na samym nginx'ie (to że Nancy go nie widzi to na 99% wina Nancy a nie serwera).
EDIT:
Teraz jak przyjrzałem się temu co się dzieje to wychodzi że to błąd z pętlą przekierowań jest... logicznym zachowaniem:
1. Wchodzę na stronę http://localhost:8080/test - tam jest sprawdzane czy adres zaczyna się od https
2. Dochodzi do przekierowania na https://localhost:443/test - czyli tak jak być powinno
3. A nginx przekierowuje to do... http://localhost:8080/test
4. Dochodzi do sprawdzanie czy zapytanie przyszło z https - nie, gdyż to nginx zapewnia https a aplikację odpytuje po http
Dalej patrz punkt 2... jednak wydaje się to być jakiś problem z konfigiem nginx'a? Będę sprawę teraz badał dalej.
Pozdrawiam.
Ostatnio edytowany przez Huk (2015-04-21 22:32:54)
Offline
Pokażesz konfig Vhosta od Nginxa? Czy może liczysz, że wyrwę na mieście wróżkę z wielkimi szklanymi kulami? :D
Ostatnio edytowany przez Jacekalex (2015-04-21 22:50:34)
Offline
Konfig się nie zmienił zbytnio z tego co zamieściłem kilka postów wyżej:
server { listen 80; listen 443 ssl; ssl_certificate /home/james/sslCert2/server.crt; ssl_certificate_key /home/james/sslCert2/server.key; server_name localhost; root /home/james/nancywebpageroot/NancyWebPage.DPL.Services/bin/Debug/; location /Content/ { alias /home/james/nancywebpageroot/NancyWebPage.DPL.Services/bin/Debug/Content/; location ~* \.(jpg|jpeg|png|gif|ico|css|js|ttf)$ { expires 365d; } } location / { proxy_pass http://127.0.0.1:8080; proxy_redirect http://127.0.0.1:8080 https://127.0.0.1:443; } }
(No chyba że nie o to chodzi? Tak jak pisałem ciemny jestem z tego) Teraz zacząłem eksperymentować z opcją:
proxy_redirect
Z dokumentacji powiedziałbym że właśnie do tego ma ona służyć - "oszukać" aplikację że request przychodzi z innej lokalizacji - bynajmniej to co jest powyżej nie śmiga :( cały czas requesty https z nginx przychodzą z http://localhost:8080 zamiast z https...
EDIT:
Hmmm wg curl'a serwer zwraca poprawny header Location z https... czyli znowu coś po stronie chyba Nancy... muszę to bardziej rozczaić - ale to jutro po robocie, bo w tej chwili zasypiam przed kompem ;]
EDIT2:
Jeszcze druga opca to rewrite URL który jest przesyłany w headerze jako pytający - z tego co czytam da się do tego zastosować moduł rewrite - ale tym będę się bawił też jutro ;]
Ostatnio edytowany przez Huk (2015-04-21 23:57:21)
Offline
Nie widziałem Twojej rzeźby z Nancyfx, ale moim zdaniem masz jednego babola, mianowicie w Nginxie nie przekazujesz zmiennych wymaganych w RFC dla proxy.
Spróbuj tak, jak napisałem tutaj:
https://forum.dug.net.pl/viewtopic.php?pid=285984#p285984
Do tego jak w Nginxie ustawisz debugowanie połączenia, to powinieneś się więcej dowiedzieć.
Tak się to wlącza:
events { worker_connections 64; use epoll; debug_connection 127.0.0.1; } http { server {...} server {...} }
To się umieszcza globalnie, powyżej kontekstu http.
Sznurek:
http://wiki.nginx.org/EventsModule#debug_connection
Jeżeli Apache tak szedł z własnym ssl przez proxy Nginxa, to ten Nancy cośtam chyba też powinien.
Ostatnio edytowany przez Jacekalex (2015-04-22 03:10:12)
Offline
Hmm udało mi się to częściowo ugryźć, w Nancy jest opcja po włączeniu której można przekazać header [b]"X-Forwarded-Proto"[/b] wtedy pętla się nie zdarza konfig wygląda tak:
server { listen 80; listen 443 ssl; ssl_certificate /home/james/sslCert2/server.crt; ssl_certificate_key /home/james/sslCert2/server.key; server_name localhost; root /home/james/nancywebpageroot/NancyWebPage.DPL.Services/bin/Debug/; location /Content/ { alias /home/james/nancywebpageroot/NancyWebPage.DPL.Services/bin/Debug/Content/; location ~* \.(jpg|jpeg|png|gif|ico|css|js|ttf)$ { expires 365d; } } location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }
Problem taki że nginx dopisuje ten header zawsze, a powinien tylko gdy przychodzi request na port 443... próbowałem dodać coś takiego:
server { listen 80; listen 443 ssl; ssl_certificate /home/james/sslCert2/server.crt; ssl_certificate_key /home/james/sslCert2/server.key; server_name localhost; root /home/james/nancywebpageroot/NancyWebPage.DPL.Services/bin/Debug/; location /Content/ { alias /home/james/nancywebpageroot/NancyWebPage.DPL.Services/bin/Debug/Content/; location ~* \.(jpg|jpeg|png|gif|ico|css|js|ttf)$ { expires 365d; } } location / { proxy_pass http://127.0.0.1:8080; if($scheme = https){ proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } }
Ale oczywiście takie coś nie działa... jest już blisko - szukam opcji żeby przekierowywać na dane location w zależności od portu ale na razie lipa... :(
EDIT:
W KOŃCU! Udało się to cholerstwo pożenić :) a rozwiązanie to taki plik konfiguracyjny (+mała zmiana w Nancy):
server { listen 80; server_name localhost; root /home/james/nancywebpageroot/NancyWebPage.DPL.Services/bin/Debug/; location /Content/ { alias /home/james/nancywebpageroot/NancyWebPage.DPL.Services/bin/Debug/Content/; location ~* \.(jpg|jpeg|png|gif|ico|css|js|ttf)$ { expires 365d; } } location / { proxy_pass http://127.0.0.1:8080; } } server { listen 443 ssl; ssl_certificate /home/james/sslCert2/server.crt; ssl_certificate_key /home/james/sslCert2/server.key; server_name localhost; root /home/james/nancywebpageroot/NancyWebPage.DPL.Services/bin/Debug/; location /Content/ { alias /home/james/nancywebpageroot/NancyWebPage.DPL.Services/bin/Debug/Content/; location ~* \.(jpg|jpeg|png|gif|ico|css|js|ttf)$ { expires 365d; } } location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }
Najpewniej da się to jakoś zrobić w jednym bloku - ale mi się nie udało znaleźć sposobu. Ważne że teraz działa - dzięki za pomoc... jeszcze jedna rzecz mnie ciekawi - czy standardowy konfig SSL w nginx jest wystarczający czy też używa on tam przestarzałych algorytmów?
Pozdrawiam.
Ostatnio edytowany przez Huk (2015-04-22 21:41:07)
Offline
To zrób sobie osobne Vhosty na 80 i 443, i na każdym ustawisz takie nagłówki, jakie potrzebujesz, co za problem?
Prawy knefel myszki, ten od kopiowania, pies zjadł?
Np Wordpress na porcie 80/tcp.
server { server_name blog.domena.tld; root /home/www/blogi/Wordpress4; listen 0.0.0.0:80; listen [::]:80; return 301 https://$http_host$request_uri; log_not_found off; access_log off; }
curl -I http://blog.domena.tld HTTP/1.1 301 Moved Permanently Server: nginx Date: Wed, 22 Apr 2015 19:41:17 GMT Content-Type: text/html Content-Length: 178 Connection: keep-alive Keep-Alive: timeout=20 Location: https://blog.domena.tld/
SOA#1
Ostatnio edytowany przez Jacekalex (2015-04-22 21:43:52)
Offline
To zrób sobie osobne Vhosty na 80 i 443, i na każdym ustawisz takie nagłówki, jakie potrzebujesz, co za problem?[/quote]
Masz na myśli rozdziel na dwa osobne pliki konfiguracyjne? Mógłbym ale nie to że w jednym jest nieco zdublowanych danych nie przeszkadza ;]
A za redirecty odpowiada aplikacja, właśnie cały sens mojej walki był taki żebym w kodzie mógł ustalić które części apki wymagają SSL by design, a które nie - jak bym miał to ustawiać z poziomu serwera to robiłbym drugi raz tą samą robotę niepotrzebnie (o tym że jak wkradłby się jakiś babol, i część apki przez to nie szła by szyfrowana nie wspominając), poza tym część apki ma być bez SSL (jakby całość miała iść z wykorzystaniem HTTPS to bym się nie pierdzielił tylko już dawno napisał coś takiego jak podałeś post wyżej ;] ).
Pozdrawiam.
Offline
1874
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:16:30)
Offline
[quote=Huk]
To zrób sobie osobne Vhosty na 80 i 443, i na każdym ustawisz takie nagłówki, jakie potrzebujesz, co za problem?[/quote]
Masz na myśli rozdziel na dwa osobne pliki konfiguracyjne? Mógłbym ale nie to że w jednym jest nieco zdublowanych danych nie przeszkadza ;]
A za redirecty odpowiada aplikacja, właśnie cały sens mojej walki był taki żebym w kodzie mógł ustalić które części apki wymagają SSL by design, a które nie - jak bym miał to ustawiać z poziomu serwera to robiłbym drugi raz tą samą robotę niepotrzebnie (o tym że jak wkradłby się jakiś babol, i część apki przez to nie szła by szyfrowana nie wspominając), poza tym część apki ma być bez SSL (jakby całość miała iść z wykorzystaniem HTTPS to bym się nie pierdzielił tylko już dawno napisał coś takiego jak podałeś post wyżej ;] ).
Pozdrawiam.[/quote]
Dwa pliki? jak lubisz?
W Nginxie Vhost ogranicza się w znacznikachKod:
server { .... }Chcesz 79 Vhostów w jednym pliku? droga wolna.
W Apachu i Lighttpd to z resztą identycznie działa.
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
Time (s) | Query |
---|---|
0.00017 | SET CHARSET latin2 |
0.00008 | SET NAMES latin2 |
0.00185 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.225.195.153' WHERE u.id=1 |
0.00257 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.225.195.153', 1732847168) |
0.01024 | SELECT * FROM punbb_online WHERE logged<1732846868 |
0.00229 | DELETE FROM punbb_online WHERE ident='85.208.96.204' |
0.00302 | DELETE FROM punbb_online WHERE ident='85.208.96.211' |
0.00287 | SELECT topic_id FROM punbb_posts WHERE id=285984 |
0.00034 | SELECT id FROM punbb_posts WHERE topic_id=27270 ORDER BY posted |
0.00105 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=27270 AND t.moved_to IS NULL |
0.00008 | SELECT search_for, replace_with FROM punbb_censoring |
0.00801 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=27270 ORDER BY p.id LIMIT 0,25 |
0.00129 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=27270 |
Total query time: 0.03386 s |