Mikseri on musiikkiyhteisö,
jossa voit kuunnella, ladata ja arvostella suomalaista musiikkia,
lisätä rajattomasti biisejä, luoda oman artistisivun, kerätä arvosteluja ja faneja

Ladataan

Vastaa Aloita uusi keskustelu

 
Kirjoittaja HTTPS testikäytössä

Salminen
Salminen
I'm back!
2532 viestiä
Ylläpitäjä

#1 kirjoitettu 18.06.2017 13:14

Mikseri.netissä on nyt testikäytössä HTTPS-tuki. Tämä lisää sivuston turvallisuutta sekä nopeutta (HTTP/2 -tuen muodossa).

https://mikseri.net/

Ennen kaiken liikenteen pakottamista HTTPS-salatuksi kaipailen rohkeita vapaaehtoisia testaamaan sivustoa ja raportoimaan tähän ketjuun mahdollisesti ilmenevistä ongelmista. Kaikki tähän mennessä testaamani sivut ovat toimineet, mutta ainakin seuraavia ongelmia voi ilmentyä:

- Jotkut tiedostot kuten kuvat, CSS ja JavaScript saattavat joillain tai kaikilla sivuilla latautua salaamattomasta HTTP-osoitteesta. Selain joko varoittaa sivun turvattomuudesta ja/tai jättää tiedoston tai jopa koko sivun lataamatta.
- Osa linkeistä ja lomakkeista saattaa ohjata selaimen HTTP-osoitteeseen, jolloin suojaus katoaa ja selain saattaa varoittaa asiasta.

Mikäli törmäät ongelmiin, vastaa tähän ketjuun ja anna kuvaus kohtaamastasi ongelmasta, käyttämäsi selain käyttöjärjestelmineen ja versionumeroineen sekä ongelmallisen sivun osoite.

Kiitos ja turvallista selailua!

^ Vastaa Lainaa

BVR
BVR
20365 viestiä

#2 kirjoitettu 20.06.2017 01:29

Onkostas tää nyt miun laskukoneen hommia, vai Mikserin juttuja? https://www.dropbox.co...

Terveisin, Pöljäeinari84

^ Vastaa Lainaa

veezay
veezay
bassofriikki
7677 viestiä
Luottokäyttäjä

#3 kirjoitettu 20.06.2017 10:58 Muok:20.06.2017 11:11

saan kuvaa (jpg, 727x727, 40kt) lisätessä virheilmoituksen "Kuvan lähettäminen epäonnistui. Yritä uudelleen." mutta sama toistuu kyllä ilman salattua protokollaakin, eli oikeastaan tää ois kannattanut kirjottaa lähinnä tonne palvelinmuutosvirheketjuun.

that being said, oon selannut tän ketjun ilmestyttyä mikseriä pelkästään https:llä ja mitään https-specific ongelmia ei oo esiintynyt.

^ Vastaa Lainaa

Salminen
Salminen
I'm back!
2532 viestiä
Ylläpitäjä

#4 kirjoitettu 20.06.2017 15:51

veezay kirjoitti:
saan kuvaa (jpg, 727x727, 40kt) lisätessä virheilmoituksen "Kuvan lähettäminen epäonnistui. Yritä uudelleen." mutta sama toistuu kyllä ilman salattua protokollaakin, eli oikeastaan tää ois kannattanut kirjottaa lähinnä tonne palvelinmuutosvirheketjuun.

Korjattu, kuvien lähetykseen oli kovakoodattu polkuja jotka eivät ole uudella palvelimella samoja kuin vanhalla.

BVR:n huomioima outo polku puolestaan on Google Chromen tietoturvaviritys, joka estää sivuja nuskimasta käyttäjän hakemistorakenteita kun kaikki uploadatut tiedostot ilmoittavat olevansa hakemistossa C:\fakepath.

^ Vastaa Lainaa

veezay
veezay
bassofriikki
7677 viestiä
Luottokäyttäjä

#5 kirjoitettu 20.06.2017 19:25

Salminen kirjoitti:
Korjattu, kuvien lähetykseen oli kovakoodattu polkuja jotka eivät ole uudella palvelimella samoja kuin vanhalla.

tattista, nyt olen rumempi kuin koskaan.

^ Vastaa Lainaa

morfin_mafer
morfin_mafer
423 viestiä

#6 kirjoitettu 22.06.2017 09:18

Mitä SSL-salauksella on tarkoitus salata? Se ei ole kovin järkevää jos vain sisäänkirjautumisen yhteydessä syötettävät salasanat ja käyttäjätunnus on tarkoitus salata. Mutta jos on tarkoitus salata ihmisten yksityisyyteen liittyvää data niin silloin se on järkevää.

^ Vastaa Lainaa

Salminen
Salminen
I'm back!
2532 viestiä
Ylläpitäjä

#7 kirjoitettu 22.06.2017 10:56

morfin_mafer kirjoitti:
Mitä SSL-salauksella on tarkoitus salata? Se ei ole kovin järkevää jos vain sisäänkirjautumisen yhteydessä syötettävät salasanat ja käyttäjätunnus on tarkoitus salata. Mutta jos on tarkoitus salata ihmisten yksityisyyteen liittyvää data niin silloin se on järkevää.

Kaikki. Miksei se ole mielestäsi järkevää?

^ Vastaa Lainaa

morfin_mafer
morfin_mafer
423 viestiä

#8 kirjoitettu 22.06.2017 14:58

Salminen kirjoitti:
morfin_mafer kirjoitti:
Mitä SSL-salauksella on tarkoitus salata? Se ei ole kovin järkevää jos vain sisäänkirjautumisen yhteydessä syötettävät salasanat ja käyttäjätunnus on tarkoitus salata. Mutta jos on tarkoitus salata ihmisten yksityisyyteen liittyvää data niin silloin se on järkevää.

Kaikki. Miksei se ole mielestäsi järkevää?


SSL-salaus vie palvelimelta resursseja enemmän kuin normaali http.. varsinkin jos palvelimella on Java:lla koodattu backendi esim. Tomcatin ja Apachen takana niin tällöin pitää sekä Tomcat ja Apache SSL-salata erikseen. Ja silloin kannattaa miettiä jos palvelimen CPU ja RAM ovat minimaaliset että kannattaako salata liikennettä pelkkien tunnusten ja salasanojen takia. Tai no ihan miten haluaa. Ei suuri ongelma jos samalla palvelimella on vain yksi sivusto eikä useampia.

^ Vastaa Lainaa

Salminen
Salminen
I'm back!
2532 viestiä
Ylläpitäjä

#9 kirjoitettu 22.06.2017 15:59

morfin_mafer kirjoitti:
Salminen kirjoitti:
morfin_mafer kirjoitti:
Mitä SSL-salauksella on tarkoitus salata? Se ei ole kovin järkevää jos vain sisäänkirjautumisen yhteydessä syötettävät salasanat ja käyttäjätunnus on tarkoitus salata. Mutta jos on tarkoitus salata ihmisten yksityisyyteen liittyvää data niin silloin se on järkevää.

Kaikki. Miksei se ole mielestäsi järkevää?


SSL-salaus vie palvelimelta resursseja enemmän kuin normaali http.. varsinkin jos palvelimella on Java:lla koodattu backendi esim. Tomcatin ja Apachen takana niin tällöin pitää sekä Tomcat ja Apache SSL-salata erikseen. Ja silloin kannattaa miettiä jos palvelimen CPU ja RAM ovat minimaaliset että kannattaako salata liikennettä pelkkien tunnusten ja salasanojen takia. Tai no ihan miten haluaa. Ei suuri ongelma jos samalla palvelimella on vain yksi sivusto eikä useampia.

Teho ei ole meillä ongelma, apachen ja nginx:n edessä oleva kevyt hitch/varnish -yhdistelmä hoitaa SSL-terminoinnin hyvin pienellä overheadilla. Kirjautumistietojen ohella mm. sessioeväste kulkee jokaisen requestin mukana ja sen kaappaamalla on mahdollista ottaa käyttäjän sessio haltuun. Siksi SSL - tai nykyään oikeammin TLS.

^ Vastaa Lainaa

morfin_mafer
morfin_mafer
423 viestiä

#10 kirjoitettu 22.06.2017 17:21

Mulla taas itsellä on 8 Core CPU:lla varustettu 8 Gt RAM:lla varustettu VPS ja siellä ajetaan Tomcatin varassa Apacheen mod_proxyllä integroituna 3 kpl eri ohjelmistoa ja nämä toimivat hiemen hitaasti mutta eivät sentään kaada palvelinta / toisiaan tehon puutteen vuoksi. Sitten on toinen palvelin jossa on 2 Core CPU ja 2 Gt RAMIa ja tämän jälkimmäisen kanssa oli isojakin tehon puuteongelmia ajaa näitä kaikkia J2EE-pohjaisia sovelluksia yhtäaikaa ja ne eivät yhtäaikaa toimineet vaan kaatoivat toinen toisensa.

^ Vastaa Lainaa

Salminen
Salminen
I'm back!
2532 viestiä
Ylläpitäjä

#11 kirjoitettu 01.07.2017 09:11

morfin_mafer kirjoitti:
Mulla taas itsellä on 8 Core CPU:lla varustettu 8 Gt RAM:lla varustettu VPS ja siellä ajetaan Tomcatin varassa Apacheen mod_proxyllä integroituna 3 kpl eri ohjelmistoa ja nämä toimivat hiemen hitaasti mutta eivät sentään kaada palvelinta / toisiaan tehon puutteen vuoksi. Sitten on toinen palvelin jossa on 2 Core CPU ja 2 Gt RAMIa ja tämän jälkimmäisen kanssa oli isojakin tehon puuteongelmia ajaa näitä kaikkia J2EE-pohjaisia sovelluksia yhtäaikaa ja ne eivät yhtäaikaa toimineet vaan kaatoivat toinen toisensa.

Mikserin palvelimelle on varattu 3 corea ja 6GB RAMia eikä vielä kertaakaan olla käyty tilanteessa jossa kaikki coret olisivat yhtäaikaa käytössä. Kannattaa tutustua kevyisiin reverse proxyihin kuten Varnish ja HAProxy (sekä hitch jos haluaa TLS:n), ne vähentävät mukavasti kuormaa etenkin Tomcatilta, jonka threadit tulevat herkästi täyteen jos useampi hidas clientti latailee yhtäaikaa isoja tiedostoja.

^ Vastaa Lainaa

Vastaa Aloita uusi keskustelu