biberu

biberu

Medlem
  • Registrerad 2012-02-04
  • Senast aktiv 2020-05-08
  • Antal inlägg 518

Foruminlägg

De senaste inläggen biberu har skrivit i forumet.

Ursprungligen av Alix:

Tack för visat engagemang. Men jag menar bestämt att inom code-taggar ska texten stå helt ren. Den ska kunna kopieras rakt av för att kunna köras direkt i Terminalen. Det är ytterst därför code-taggningen finns.

Nja, det främsta syftet med kodtaggen är att bevara formatering, och det är meningen att det ska vara lätt att bara droppa en länk till dokumentation eller liknande i de här blocken. Om det är kritiskt att exemplet ska kunna köras direkt i terminalen och länkformateringen saboterar det så är det lättaste att omge kodsnutten med [noparse]-taggar:

Syntax:

[code][noparse]/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"[/noparse][/code]

Resultat:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

@Alix: Avsikten är att de ska tolkas, och kortas av, automatiskt även inuti kodstycken. Däremot ser jag att den hade råkat svälja slutparentesen som del av länken i den där situationen så jag justerade det istället, så nu ser man slutet av kommandot som förväntat. Hoppas det hjälper.

Ursprungligen av reboot81:

Vad behövs för att HTTPS ska bli verklighet på GP's siter? @hansfilipelo verkar ha koll på terminologin, vem mer finns ute i stugorna som är insatta i ämnet?

För att kunna aktivera det över hela siterna, vilket egentligen är den enda riktiga lösningen, så måste vi komma bort från problem med mixed content (tredje part utan eller med ogiltiga certifikat). I praktiken innebär det främst annonsleverantörer, och det tar tid för hela det skeppet att vända. Situationen ser dock bättre ut idag än den gjorde för ett år sedan; har kört en av våra mobilsiter på HTTPS ett tag och kommer troligen flytta över en annan för att testa och driva på mer snart.

Det andra alternativet är att, som på SweClockers, krypera endast sidor som rör kontohanteringen, men det är dels en otillräcklig lösning och kräver dels mer tid som inte finns idag. Jag är ensam utvecklare och det är många bollar i luften, och ibland måste man ärligt talat göra mindre roliga prioriteringar. Det är också en situation jag hoppas kunna lösa framöver.

@reinventor: Underligt. Det görs ingen skillnad på de två adresserna i vårat system, och de tycks ju gå iväg som de ska härifrån. Är det något annat som skiljer hos dig? Olika eller flera klienter kopplade till något av kontona?

@IngoX: Tanken med detta var dels att den som besvaras ska notifieras, och dels att den som besvarar ska påminnas om att inlägg pekar tillbaks på tidigare delar av diskussionen. Vill man rikta ett svar till specifika användare så bör man överväga att @nämna eller citera så att övriga läsare lättare kan plocka upp sammanhanget. Den stora nackdelen med just den här varianten är att det blir ett extra steg att göra ett genrellt tillägg till diskussionen, men det är i.v.f. bakgrunden...

Har ändrat detta så att det fungerar som du föreslår nu: det blir inte längre några automatiska citat av trådstarten via det första inlägget. Strular det så prova rensa cache.

Ursprungligen av hansfilipelo:

Jag skulle vilja lyfta den här frågan igen. Det känns inte ansvarsfullt att tusentals användares lösenord skickas i klartext, och särskilt då ingen förklaring till varför det är så ges.

Svaret är tyvärr samma än:
http://www.99mac.se/forum/p/2245438

Ursprungligen av Jesper Ohlsson:

Att i efterhand kunna gå in och "justera debatten" och "städa efter sig" när man har fått en kontroversiell tråd stängd borde inte vara möjligt.

Tack, nu går det inte längre att redigera i stängda trådar.

Ursprungligen av Cancerman:

Man får tacka
Får man fråga sig varför inte fullskärmsläge har fungerar tidigare? Ping @biberu

Tidigare var det bara en direkt embed av youtubes iframe, och den verkar inte längre gå att köra i fullskärm. Lade in videon via javascript-api:t nu istället.

Ursprungligen av zinned:

Jag förstår det du säger men en följdfråga, då jag tycker detta är intressant:

Dessa alternativa möjligheter som du beskriver, de kräver väl i sig också möjligheten att köra scripts för att i sig kunna köras. Om den möjligheten är strypt, hur exekveras då dessa kontroller?

Titta på hur övrigt material laddas, logga och knyt det till något du kan använda för att identifiera besökaren. Efter det är det bara att leverera annan, statisk information istället för / tillsammans med den efterfrågade sidan nästa gång. Det är dock väldigt få användare som inaktiverar scripts; dels är det många som inte är medvetna om möjligheten och dels tenderar det att få negativa konsekvenser för funktionaliteten. Det är inte heller viktigt att nå precis alla, och de allra flesta kör bara med standardinställningar och gör inga extra försök att maskera det.

Ursprungligen av zinned:

Men om innehållsblockeraren blockar script på sidan så sker ju aldrig det och att de gör just detta är väl nästan default...?

Man kan ha andra scripts på plats som tittar på om de första tillåts köra. Inte ens att stänga av scripts helt döljer huruvida man annonsblockerar eller ej; det går fortfarande att titta på hur övrigt material laddas in. Annars kan man helt enkelt se till att sidan inte blir användbar utan scripts aktiverade (om den inte redan var det, det är få användare som surfar med JS inaktiverat och det är inte nödvändigtvis varken möjligt eller värt investeringen att implementera alternativ) och adblock inaktiverat (eller tillräckligt maskerat).

Ursprungligen av zinned:

Du menar att scripten kan kolla detta?

Ja.

Ursprungligen av Demiurgen:

Jag fattar inte hur http-servern - t.ex. CNET - kan veta att man har en plugin som steker annonser. Finns det verkligen inget sätt att skriva koden så att plugin'en är "stealth" - varför behöver den över huvud taget berätta något UTÅT? Jag undrar av ren nyfikenhet och är novis när det gäller html och http-servers. Någon som har tips om info om detta? Länk?

Pluginen behöver inte aktivt meddela något, det räcker att leta efter konsekvenserna. Man kan kontrollera om annonser laddats och körts, om de är synliga på sidan m.m. och sedan använda denna information för att t.ex. visa information om annonsblockering eller begränsa åtkomst till material på olika sätt.

(@Megolon)

*** Raderat ett inlägg som bröt mot forumets trivselregler. ***

Ursprungligen av hansfilipelo:

Korrekt confad webbserver med ett giltigt cert garanterar serverns identitet och skickar data krypterat (sen om den är hackad är det en annan sak). Övriga sidöverföringar skickar inte lösenordet (vilket vi redan tagit upp) så det är att jämföra äpplen och päron. Du måste inte ladda de sidorna över https.

Den mest direkta attacken är givetvis att endast försöka avlyssna endast lösenordsöverföringen, men det är inte tillräckligt att kryptera bara dessa.

Ursprungligen av hansfilipelo:

...

Har avsett att ge insyn inte varför det inte finns än, inte lämna ursäkter, samt diskutera problematiken i allmänhet. Det är synd att det har missförståtts, men jag har noterat ditt önskemål.

Ursprungligen av hansfilipelo:

Visste inte att ni hämtade mer material från andra siter än annonser, av ren nyfikenhet från min sida - vad är det för material?

Jag menar att det inte räcker att bara kryptera vissa sidladdningar, du kan fortfarande attackera resterande överföringar på olika sätt. Än mer hypotetiskt så går det inte heller att anta att en sida vars resurser hämtats över HTTPS endast utför vad som avsetts.

Ursprungligen av hansfilipelo:

Ingen personlig kritik - som admin vet jag av erfarenhet att man brukar vara först att lyfta de här frågorna. Det mer att jag tycker många organisationer tar för lätt på säkerhetsfrågorna och säger att "man varit tvungen att prioritera annat" - detta samtidigt som man haft tid att lansera en ny version av siten utan att bättra säkerheten kring lösenordshanteringen.

Jag tror du överskattar organisationens storlek en aning, och lösenordshanteringen *har* förbättrats gentemot den förra versionen av siten.

Senast redigerat 2015-07-22 14:04