Mikseri.net

#2 kirjoitettu 20.06.2017 01:29

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

Terveisin, Pöljäeinari84

#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.

#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.

#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.

#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ää.

#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ää?

#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.

#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.

#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.

#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.