Muutama sivusto ja kanava mitä on tullut seurailtua. Kaikki ei liity suoraan web-kehitykseen, mutta sivuavat aihetta tai alaa.
name: End-to-end tests
on: [push, pull_request]
jobs:
cypress-run:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v1
- name: Use Node.js
uses: actions/setup-node@v1
- run: |
npm install
npm run start:ci
working-directory: backend
env:
TEST_MONGODB_URI: ${{ secrets.TEST_MONGODB_URI }}
JWT_SECRET: ${{ secrets.JWT_SECRET }}
RECAPTCHA_SECRET_TEST: ${{ secrets.RECAPTCHA_SECRET_TEST }}
- name: Cypress run
uses: cypress-io/github-action@v1
with:
working-directory: frontend
config-file: frontend/cypress.json
start: npm run start
wait-on: http://localhost:3000
Olisko tämä:
Ei ollut tuo. Sain tuon kuitenki toimimaan näin:
name: End-to-end tests
on: [push, pull_request]
jobs:
cypress-run:
runs-on: ubuntu-16.04
steps:
- name: Checkout
uses: actions/checkout@v1
- name: Use Node.js
uses: actions/setup-node@v1
with:
node-version: 12
- run: npm install
working-directory: backend
- name: Cypress run
uses: cypress-io/github-action@v1
with:
working-directory: frontend
config-file: cypress.json
start: npm run start:ci
wait-on: http://localhost:3000
env:
TEST_MONGODB_URI: ${{ secrets.TEST_MONGODB_URI }}
JWT_SECRET: ${{ secrets.JWT_SECRET }}
RECAPTCHA_SECRET_TEST: ${{ secrets.RECAPTCHA_SECRET_TEST }}
Oletan, että kieli on edelleen JavaScript: JavaScript Functions
//functio
function tutkiKumpiOnSuurempiLuku(luku1, luku2){
if(luku1 > luku 2){
return luku1;
}
if(luku1 < luku2){
return luku2
}
}
//Esitellään muuttujat
var luku1 = 1;
var luku2 = 2;
//Kutsutaan funktiota
tutkiKumpiOnSuurempiLuku(luku1, luku2);
Itse käsitin tuon tehtävänannon, että pitäisi antaa yhtenä parametrina, eli objektina. En tosin tiedä, mitkä niiden avaimien nimet olisivat ja miksi näin pitäisi tehdä? En myöskään ymmärtänyt, että mihin väliin se `.call()` pitäisi upottaa, tai mikä on se use case.
const tutkiKumpiOnSuurempi = (a = 0, b = 0) => ((a >= b) ? a : b);Onks tossa yks sulku liikaa. Ihan hölmö tehtävä muutenkin kun on jo
Math.max(1,2);Millälailla turvallinen? Kaikki data frontissa on käyttäjän luettavissa ja muokattavissa helposti. JWT:n turvallisuushan perustuu allekirjoitukseen, jotta serveripäässä voidaan luottaa ettei tokenia ole muokattu.
Hmm... olen varma, että poistin sen kun aluksi tosiaan tuli yksi sulku liikaa. Mutta näköjään jäänyt tuohon, teen ninja-editin.
Pitäskö tuosta lopuksi tulla ruutuun joku alert?
Turvallisin paikka on ihan vaan muistissa lyhyellä voimassaoloajalla ja sitten refreshaat sitä. Täällä esim. aika hyvää settiä: The Ultimate Guide to handling JWTs on frontend clients (GraphQL)
alert(tutkiKumpiOnSuurempiLuku(luku1, luku2));Jos joku saa käsiinsä tuon tokenin joka on tallennettu local storageen, niin sillä pystyy tekemään kyselyitä rajapintaan.
Täytyy tutustua tähän.
Vaikka sillä tavalla, että local ja session storeen pääsee käsiksi millä tahansa koodin pätkällä mitä sivulla ajetaan. Joten XSS tilanteessa tokeni on käytännössä alttarilla odottamassa ottajaansa.
Muuta luvut integeriksi ennen vertailua.
//Ohjelma ilmoittaa kahdesta käyttäjän antamasta luvusta suuremman
var luku1 = prompt("Anna ensimmäinen luku",0);
var luku2 = prompt("Anna toinen luku",0);
var a = parseInt(luku1);
var b = parseInt(luku2);
//Kutsutaan funktio
alert(tutkiKumpiOnSuurempiLuku(a, b));
//functio
function tutkiKumpiOnSuurempiLuku(luku1, luku2){
if(luku1 > luku2){
return luku1;
}
if(luku1 < luku2){
return luku2
}
}Nuo jutut ovat alkuun kompastuskivinä jonkun aikaa ja ennen kuin vuoden - kaksi opettelee niin aika paljon näihin pieniin asioihin juuttuu kiinni. Googlesta löytyy paljon vastauksia, kun osaa hakea oikeilla hakusanoilla. Alkuun siis stackoverflow yms. ovat ihan hyviä apusivuja.
@font-face {
font-family: 'SuperLegend';
font-display: fallback;
src: local('SuperLegend'),
url('./fonts/SuperLegendBoy-4w8Y.ttf') format('truetype');
}
.jokuClass {
font-family: 'SuperLegend', Helvetica, sans-serif;
}Mitäs selaimen devtools -> network sanoo fontin lataamisesta?
200 OK.
Nimenomaan ja kenties kynnystä nostaa sekin että saa olla tarkkana. Yksikin väärä tai puuttuva merkki tekee sen ettei toimikaan toivotulla tavalla.
Tästä ei pääse koskaan eroon. Vieläkin tulee mielenkiintoisia juttuja vastaan kun jättää yhdet sulkeet tai välimerkin pois vaikka koodastusten aloituksesta taitaa olla jo yli 30v.
Tähän tottuu, kun enemmän koodaa varsinkin, kun alat ymmärtämään debuggerin ja konsolin oksennusta vähän paremmin.
Veikkaisin, että tuo fontti imaisee tuon tyylin jostain sen jälkeen, kun tuo määrittämäsi opacity on ladattu. Jos selaimen style -välilehdeltä vaihdat tuon 0.01 -> 95% niin muuttuuko oikeaksi?200 OK.
...ja löysinkin juuri ongelman. Tuo teksti on elementissä, jolle olen merkinnyt opacity: 95%. Jostain syystä buildin aikana tämä vääntyy muotoon opacity: 0.01, joten tekstiä ei vain näy.
Kun kävin sörkkimässä opacity.css:n pois ja font-display: swap; , niin fontti alkoi toimia. Sitten vain ihmettelemään, miksi buildi muuttaa opacity: 95% -> opacity: 1%.
Ja tällekin löytyi syy: CSS - "opacity" percentage values are bundled incorrectly. · Issue #7980 · facebook/create-react-app
Tuota tosiaan sattuu pidempäänkin koodanneelle ajoittain mutta tuossa auttaa ainakin itseäni paljon editori jossa on syntax highlight, sulkujen mätsäys sun muut vastaavat apuvälineet. Itse en ole ammattikoodari ja editorina tulee pääsääntöisesti käytettyä vim:iä.
Visual Studio Code on ihan näppärä. Tai no, yksi parhaista.
Visual Studio Code on de facto öbaut paras valinta webbitekkien koodaukseen. Todella monipuolinen, nopea ja vauhdikkaasti kehittyvä editori, josta ei puutu mitään.
Toi on kyllä monimutkainen esimerkki joka perustuu mikroarkkitehtuuriin. Ymmärsit ihan oikein ja tosiaan vaatii tietokannan. Esim. redis tai joku muu no-sql käy hyvin. @nnaku taisi olla sitä mieltä että token suoraan vaan ilman refreshtoimintoa httpOnly keksiin, joka toteutuksena yksinkertaisempi. Tässä omat tietoturvariskinsä, mutta varmasti parempi kuin localstoressa.
Mikähän mahtaisi olla yksinkertaisin toimiva systeemi, jos mennään pelkällä Access Tokenilla?
Lähtökohtaisesti pelkkä pitkäikäinen access token on kyllä aika huono idea ja JWT:tä ei ole suunniteltu siihen. Eikä se toteutuskaan ole yksinkertainen vaikka sen siten tekisikin, koska uloskirjautuminen tarkoittaa blacklist tietokannan (varmaan taas redis on paras) luomista jonne pistät sen JWT tokenin millä "kirjaudut ulos". Muista että kerran luotu pitkäikäinen JWT on voimassa ja validi koko sen eliniän ajan huolimatta siitä kuka sitä käyttää eikä ilman tietokantaa sitä voi mitenkään invalidoida. Tässä hieman lukemista logout-toiminnallisuudesta:
Ehkä JWT ei sovellu mun käyttötarkoitukseen. Täytyy tutustua nähin.Lähtökohtaisesti pelkkä pitkäikäinen access token on kyllä aika huono idea ja JWT:tä ei ole suunniteltu siihen. Eikä se toteutuskaan ole yksinkertainen vaikka sen siten tekisikin, koska uloskirjautuminen tarkoittaa blacklist tietokannan (varmaan taas redis on paras) luomista jonne pistät sen JWT tokenin millä "kirjaudut ulos". Muista että kerran luotu pitkäikäinen JWT on voimassa ja validi koko sen eliniän ajan huolimatta siitä kuka sitä käyttää eikä ilman tietokantaa sitä voi mitenkään invalidoida. Tässä hieman lukemista logout-toiminnallisuudesta:
Täällä taas auth0 blogi refresh tokeneista: Refresh Tokens: When to Use Them and How They Interact with JWTs
Eli kyllä melkein menisin refresh tokenilla jos kerran JWT-toteutuksen meinaat tehdä.
Kuulostaa vähän siltä että HTTP Sessions olisi tässä tapauksessa parempi vaihtoehto JWT:lle? Esim. käyttämällä expressjs/session
Toinen vaihtoehto tosiaan on autentikaatiopalvelun käyttämistä. Esim. Firebase Authenticationissa pystyy myös manuaalisesti (eli admin luo käyttäjät suoraan firebaseen ilman rekisteröitymistä) tekemään käyttäjiä.
Tarvin vain muutaman käyttäjän tähän ja ne luodaan siis "manuaalisestin". Käyttäjän ei ole mahdollista itse luoda tunnuksia.
Yksi helppo ja karvalakkimallinen JWT-toteutus olisi tehdä siten, että pidät tokenia voimassa yhden päivän eli vaikka 12 tuntia. Pistät JWT:n httpOnly keksiin, ei blacklist-tietokantaa tai refreshiä ja logout-rutiini poistaa keksin käyttäjän selaimesta. Tässä mallissa miinuksena se että käyttäjät joutuvat kirjautumaan uudestaan palveluun joka 12 tunti kun token vanhenee, vaikka eivät olisi kirjautuneet ulos ja käyttäisivät aktiivisesti palvelua. Päivittäin palvelua käyttävät käyttäjät joutuvat siten kirjautumaan joka päivä uudestaan palveluun.
Itse menis simppelissä prokkiksessa (firebasella mutta jos ei mahdollista niin...) Express-Sessiolla ja siihen kylkeen sequelize + sqlite ja bcryptillä passun validointi...
Teet olion jolla on toString tai miksi ikinä haluatkaan sitä fn kutsua.
function Person(firstName,lastName){
this.firstName = firstName;
this.lastName = lastName;
this.toString = function(){
return this.firstName+' '+this.lastName;
}
}
const Pekka = new Person('Pekka','Puupää')
Pekka.toString() /* -> Pekka Puupää */
