biberu

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.

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

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

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

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.

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.

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

Ja.

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

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.

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.

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.

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