HTTP server

[Anzure]

Hva er den sikreste plattformen?

 

Å lage egen er lite lurt, fant fort måter å hacke tilgang til resten av serveren haha. Synes Tomcat server veldig bra ut, men er det sikkert nok? Tenker banksikkert. Skal ikke bruke så mye EE-tukkel, bare scripte og kommunisere med Java-backend koden.

Må være Java da, det jeg kan best.

[Emsal]

Hvordan klarte du å hacke deg selv? Var det på autentisering av bruker?

[quantum]

Scripte? Hva slags script? Hva slags Java backend?

[Anzure]

Hvordan klarte du å hacke deg selv? Var det på autentisering av bruker?

Nei, og ikke noe sql injection. Kunne få lese tilgang utenfor webmappa, var en simpel fiks for det. Men mulig det er mye annet som jeg ikke har tenkt på engang.

 

 

Scripte? Hva slags script? Hva slags Java backend?

Du vet, 1+1 og 3*1 osv. Ikke noe fancy greier. Må gå å teste passord ovenfor databasen osv, det må også gå å ha en bakgrunns-prosess som alltid kjører hvor jeg kan kommunisere med Sockets (så jeg kan koordinere servere med hverandre).

Tomcat kan alt dette på en veldig enkel måte, så ser ut som det beste alternativet. 

[quantum]

Det du beskriver her kalles regning og ikke scripting, og den typen regnestykker du sier serveren din skal løse er det bedre å regne i hodet. Så jeg tror egentlig ikke du har forsøkt å svare på hva det er du har tenkt å lage en gang. Det er helt normalt, det kan være vanskelig nok i seg selv å forstå hva man skal lage mange ganger.

 

Men det ser i hvert fall ut til at du bruker Java og Groovy. Groovy kan vel kanskje kalles et slags script-språk, og til og med Java har jo fått et konsoll som kjører kode as you type nå. Anyway, både Java og Groovy er solide språk og deler samme plattform og økosystem, og siden Java brukes mye i finansbransjen så blir jo ikke banken så mye sikrere enn Java, så man kan godt si at Java er så sikkert som banken :-)

 

Så har du også sagt at du ikke skal drive med noe EE-tukkel, men så beskriver du etterpå akkurat noe som høres ut som nettopp EE-tukkel. Da syns jeg du skal bruke det du alt har lært "the hard way"; Ikke finn opp hjulet på nytt. Klienter som skal snakke med server, servere som skal synkroniseres med hverandre, sikkerhet, alt dette er EE-ish.

 

Sett deg inn i Spring Boot eller EE4J (eller hva det heter i disse dager.) Det fins utallige tutorials som forklarer hvordan du f.eks. kan sikre rest-api'er med Spring Security. Både Spring Boot (start.spring.io) og Wildfly Swarm (thorntail https://thorntail.io/generator/)kan generere opp prosjekter for deg med alt du trenger.

 

Hvis du forklarer litt mer hva det er du driver med kan du sikkert få mer konkrete tips. Hvorfor skal serverne synkroniseres? Trenger du SSO eller bare kryptering? Hvem er brukerne av systemet? Hvaslags miljø kjører løsningen i? Osv...

[Anzure]

Sant, burde bruke det som fins fra før. Derfor jeg bestemte meg for å lære Tomcat og JSP, istedet for å lage eget oppsett. Ser egentlig ikke noen begrensinger med Tomcat og JSP, utenom at man må gjøre alt selv da.

 

Skal ikke ha REST API, så er kanskje litt unødvendig å lære seg Spring Boot da? Det virker veldig innviklet.

Vanlige Java har jo SSLSocket, så er null problem å kommunisere med andre servere da. Mulig Spring har en raskere løsning på det, for det tar litt tid å sette opp SSLSockets. Tenkte å synkronisere databasen for å ha en fallback server på en annen lokasjon.

[quantum]

> utenom at man må gjøre alt selv da.

 

Tvert imot, vil vel mange si ...

 

> unødvendig å lære seg Spring Boot da? Det virker veldig innviklet.

 

Tvert i mot. Spring Boot er laget med ett mål for øye, å gjøre ting enkelt for deg. 

 

> Tenkte å synkronisere databasen

 

Nok et veldig godt eksempel på funksjonalitet du ikke skal lage selv. Annet enn for moro skyld da, du vil utvilsomt lære mye av det. Noen databaser har cluster og synkroniseringsfunksjonalitet akkurat til dette formålet. Spesielt CockroachDB har en spennende tilnærming som du kunne tatt en titt på, ellers har vel alle de mye brukte RDBMS'ene en eller annen løsning. 

 

Sikkerhet er som sagt et annet eksempel hvor man ikke skal lage alt selv, men du sier fortsatt ikke noe om hva du er ute etter så da er det ikke så mye mer å si om dét.

[Anzure]

Blir vel feil å si det er unødvendig å lære seg Spring Boot, men det er ikke vits å bruke det uten grunn. Må først ha noe Spring Boot faktisk kan gjøre "enklere".

 

CockroachDB ser faktisk veldig spennende ut, takk for tipset  Visste egt ikke om databaseprogramvarer som synkroniserer seg i sanntid.

 

Når programvarer har veldig mye funksjonalitet, langt mer enn jeg har bruk for og er til en viss grad nytt... da blir jeg litt usikker på sikkerheten fremfor fordelen. Skriver man koden selv, får man akkurat det man trenger og ikke det man ikke har bruk for.

[quantum]

Blir vel feil å si det er unødvendig å lære seg Spring Boot, men det er ikke vits å bruke det uten grunn. Må først ha noe Spring Boot faktisk kan gjøre "enklere".

 

CockroachDB ser faktisk veldig spennende ut, takk for tipset  Visste egt ikke om databaseprogramvarer som synkroniserer seg i sanntid.

 

Når programvarer har veldig mye funksjonalitet, langt mer enn jeg har bruk for og er til en viss grad nytt... da blir jeg litt usikker på sikkerheten fremfor fordelen. Skriver man koden selv, får man akkurat det man trenger og ikke det man ikke har bruk for.

 

CockroachDB er laget av noen av de samme folka som utviklet Googles Spanner database, og det var et ganske krevende prosjekt, tror de hadde en beta-periode på åtte år ... verdt å google historien bak. Men f.eks. MySql og PostgreSQL har også synkronisering. Pluss allverdens noSQL-databaser seff, men de er ofte ganske spesialiserte, f.eks. for lagring og søk i dokumenter.

 

Enig i at man skal være litt selektiv og kritisk til å bruke allverdens rammeverk hele tiden. Men samtidig er det ofte ting man selv og andre ikke tenker på i første omgang, og så må man legge på og legge på og legge på funksjonalitet, og plutselig har man skrevet en god del av det man kunne fått "gratis" med Spring Boot f.eks.

 

Generelt, både Spring og EE4J, og andre rammeverk også, bygger på et prinsipp som kalles Inversion of Control (IoC). Vanligvis skriver man jo et program som starter i main-metoden, og så følger det en programflyt, og eventuelt gjør kall til api'er og tjenester. IoC betyr isteden at dette snus på hodet, Det fins en container, som er laget mest mulig som et "generelt" program, hvor main-metoden ligger. Så blir programmene dine, eller komponentene som de ofte kalles, brukt som plugin-moduler isteden. De må oppfylle en viss kontrakt overfor containeren, typisk implementere et API, og så er det containerens ansvar å bruke din implementasjon av api'et på riktige tidspunkt, f.eks. når det okmmer en http-request. Meningen med dette er at du skal få mye gratisfunksjonalitet, håndtering av http-requester, databasetransaksjoner, jms-meldinger, sikkerhet osv, men nedsiden kan være at det er vanskelig å konfigurere og vanskeligere å forstå hva som skjer når noe ikke virker. Men når man lager litt større systemer blir ting komplisert uansett, og da er det som regel en fordel å gjøre det litt lettere for seg selv ved å bruke slike rammeverk isteden for å skrive absolutt alt selv, de er som regel velprøvet og bugfrie, noe jeg sjelden kan si om min egen kode første gang den kjører... Dessuten må all kode vedlikeholdes, og da er det bedre å bruke rammeverk laget av andre, som blir vedlikeholdt av andre, enn å skrive all rammeverkskode selv, som man selv må vedlikeholde. Da drukner man i arbeid.

 

Veldig få som jobber som utviklere slipper unna uten å bruke rammeverk og containere, så det kan sånn sett være lurt å sette seg inn i. Men for å lage mindre programmer som ikke er så kompliserte er det ikke sikkert det er noe å vinne på det, annet enn at man lærer noe.