Gå til innhold

Virkelig en drømmevever. Noen ganger kan man spare seg til fant


Gjest Slettet+9871234

Anbefalte innlegg

Det er vel som har påstatt det :)

 

Jeg besvarte kun SINIPPSAT, som igjen kommenterte meg:

 

Selv om jeg tok litt i, i min påstand om at CGI var eneste alternativet. Men, det er det enkelste alternativet å implementere, men det eksisterer flere python template-motorer som lar deg gjøre omtrent det samme (nevnt tidligere).

Joda, du bare fikke det til å virke som et argument for CGI fordi du ikke rett ut av boksen kan få en WSGI-applikasjon til å fungere slik som du bruker PHP. Det er et ekstremt overkommelig problem, og ikke egentlig WSGI sin feil.

Lenke til kommentar
Videoannonse
Annonse
Gjest Slettet+9871234

PhoneGap gir deg vel heller egentlig ikke en native app. Det er en HTML5-app pakket inn i en native wrapper.

 

Jeg er vel enig med deg i at Greg Rewis er upresis nå han i videoen ovenfor hevder at man kan bruke html, JavaScript og CSS til lage native applikasjoner for ulike platformer. Som vist i videoen trenger man en nøkkel for å kunne lage natvie iPhone og iPad applikasjoner. Han påstår at man bruker JavaScript + PhoneGap til å trenge inn i filsystemet, geo lokasjons delen etc.

 

Mener du at han burde sagt hybride i stedet for native applikasjoner?

 

Og å bruke curl på den måten der ser jeg ikke som annet enn et _ENORMT_ sikkerhetshull. Ok. Så trenger du bare å endre kode én plass, men det betyr også at de som bryter seg inn kun trenger å bryte seg inn én plass så har de tatt ned hele nettverket ditt. Eller hvis du koder feil, så er plutselig hele nettverket ditt nede.

 

 

Jeg har lenge brukt cUrl på den måten uten problemer. Jeg får ta problemene den gang noen hacker seg inn i koden. Da er det vel bare å gjøre min hoster oppmerksom på det, slette all kode og laste opp alt på nytt.

 

Den nye ftp funksjonaliteten i DW CS6 er ganske rask:

 

http://tv.adobe.com/...reamweaver-cs6/

 

Her

 

http://tv.adobe.com/...ng-html5-video/

 

er en annen video som viser hvor enkelt det er å embedde videoer i ulike formater til din site uten å importere dem fra en tredje part som YouTube.

 

Med video redigerings verktøy fra for eksempel http://www.wevideo.com/ øker produktiviteten dramatisk. Lager man videoer med samme navn men i ulikt format, tar DW CS 6 seg automatisk av html taggingen for de andre formatene.

 

Og det er lett å bruke DW sammen med mine favoritt rammeverk som WordPress og drupal:

 

http://tv.adobe.com/watch/learn-dreamweaver-cs6/what-is-dreamweaver-cs6/

Endret av Slettet+9871234
Lenke til kommentar
Gjest Slettet+9871234

Og der forsvant all din kredibilitet...

 

Nå får nybegynneren en oppgave som jeg forventer han kan løse siden han kommer med slik en bastant påstand. Vi bruker php som språk.

  1. Jeg regner med at du kjenner multi site (domene) installasjon fra en felles kodebase i minst et CMS system som for eksempel WordPress eller drupal. Begge er programmert i php. De to plattformene har multi site installasjons muligheter.
  2. Vis da at den måten jeg bruker php cURL på er mindre sikker enn den måten du foreslår, gjerne ved å studere hvordan multi site installering fra en felles kodebase gjøres andre steder.
  3. Du må gjerne vise en egen sikrere måte å installere felles kode på enn metoden antydet i 1 og 2 ovenfor.

Så får andre avgjøre hvem som sitter igjen med høyest troverdighet til slutt. Jeg venter ikke å høre mer konstruktivt fra deg i denne tråden.

 

Så får vi også vurdere det den annonyme brukeren @andretnet skriver i fremtiden. Det er nok forståelig at han velger å være annonym så kredibilitet ikke kan knyttes til en lett identifiserbar person.

Endret av Slettet+9871234
Lenke til kommentar
  • 1 måned senere...
Så får andre avgjøre hvem som sitter igjen med høyest troverdighet til slutt.

... og det er nok desverre ikke den anonyme brukeren kgun, sikkerhetsstrategien

 

1) la hackeren bryte seg inn

2) tette hullet etter at skaden er oppstått

 

er helt uholdbar uansett hvor mange multisite cms-installasjoner du har proppet hodet ditt med ...

  • Liker 2
Lenke til kommentar
Gjest Slettet+9871234

Nei, det er ikke min strategi. Jeg prøver selvsagt å maksimere sikkerheten. Jeg mener at bruk av cURL er sikrest. Jeg vil gjerne vite hvorfor og om du mener noe annet.

 

Dermed mener jeg at mine egne multi site installeringer er sikrere enn wordpress og drupal multi site installasjon. Jeg tar regelmessig oppdateringer.

 

Les her

 

Drupal, drush and putty, fast and secure.

 

Note: A backup of your project will be stored to backups directory if it is not managed by a supported version control system
.

hvordan jeg oppdaterer min drupal site med drush. Drush genererer automatisk en backup. I tillegg tar jeg regelmessige sikkerhetskopier av siten og databasen med noen museklikk i cPanelet.

 

Hva mener du kan gjøres bedre?

Endret av Slettet+9871234
Lenke til kommentar
Gjest Slettet+9871234

fint, da bør du jo holde deg til din egen strategi, og ikke gjøre det stikk motsatte, som du blir sitert på i http://www.diskusjon...post&p=20112572

 

Da burde du gjerne gå lenger enn til sitatet til en som ser ut til å ha forsvunnet fra denne tråden.

 

Dersom du blar deg bakover i tråden - gjør hjemmeleksen din - kommer du til denne

 

http://www.oopschool...c.php?f=9&t=261

 

posten. Jeg har enda ikke fått noe svar på hvorfor den bruken av cURL er mindre sikker enn å gjøre det uten bruk av cURL.

 

Det er en triviell kommentar at om man bryter seg inn i en felles kodebase, kan alle sitene som deler den koden hackes. Jeg prøver selvsagt å unngå at noen bryter seg inn på ett eneste sted.

 

"Don't Repeat Yourself".

 

DRY, er et prinsipp for minimalisme. Jeg har også andre sikkerhetsstrategier, men de nevner jeg ikke her.

 

Jeg regner med at flere av dere som kommenterer i denne tråden er programmerere. Det er betegnende at dere ikke kan komme med annet enn påstander og ikke et eneste eksempel på hvordan koden kan gjøres sikrere, endog uten å sjekke problemstillinjgen på en ordentlig måte.

 

"Security by obscurity", n - kopier av koden er ikke sikkerhet. En kopi av en sikrest mulig kode burde holde.

 

Kom med forslag til å gjøre koden sikrere i stedet for å komme med ubegrunnede påstander.

Endret av Slettet+9871234
Lenke til kommentar
Gjest Slettet+9871234

Kvitt deg med manuelle rutiner! Manuelle rutiner i seg selv er et sikkerhetsproblem!

 

Det var da en svært bombastisk påstand. Jeg har blandet erfaring med såvel automatiske som manuelle rutiner. Det kommer an på hva man gjør. Når jeg bruker drupal kan jeg oppdatere drupal på minst 4 måter:

  • Drush som jeg foretrekker. Rask, sikker og automatisk.
  • Laste ned filene på egen Pc og laste dem opp til web serveren.
  • Oppdatere dem fra kontrollpanelet i drupal. Automatisk og minst sikker slik jeg har erfaring med fra blant annet WordPress.
  • Via fil systemet i cPanel på min web server.

Slik

 

drush pm-update wysiwyg

 

oppdaterer jeg min drupal site med drush og slik

 

drush pm-update twitter

 

oppdaterer jeg twitter modulen (utvidelsen).

 

Kilde: Drupal, drush and putty, fast and secure.

 

Stort enklere kan det vel ikke gjøres.

Endret av Slettet+9871234
Lenke til kommentar
Gjest Slettet+9871234

  • Hvorfor stiller du det spørsmålet?
  • Hvordan er det relevant til det emnet jeg diskuterer om cURL for multi site installasjoner kontra den måten WordPress og drupal gjør det på?

Veldig lite om noe av det innholdet du legger på nettet er sikkert. Greier du å registrere en bot som en bruker på et nettsted, kan boten stjele alt arbeidet ditt på sekunder. For eksempel ligger lovdata helt åpent på nettet. Den informasjonen kan stjeles av en bot på sekundrer. Andre deler av lovdata krever innlogging. Da er det bare å registrere en bruker i botens navn og med en kjent nettleser som bruker agent og vips så er innholdet stjålet på sekunder.

 

Se: Is your online password protected database on a secure server really secure?

 

Mange tror for eksempel at det er nok å nekte boten adgang ved disallow i robots.txt. Det holder ikke. Det holder endog ikke om du har nektet adgang ved å nekte botens Ip adresse adgang. Så lenge der er en lenke til en artikkel på den siten du trodde var sikker, kan avanserte site crawlere finne innholdet ditt.

 

Jeg skriver kun innhold. Hva skulle jeg frykte?

 

Det aller verste er at noen brukes slike boter til artikkel spinning på den teksten som "mines" fra nettet. Hvorfor tror du? Som du sikkert har gjettet, for å tapetsere nettstedene dine med bot generert innhold og reklame (for eksempel AdSense) på siten.

 

Les mer her:

 

Copy scape and duplicate content - more confusing than convincing.

 

This is a survey of existing and proposed laws and regulations on cryptography - systems used for protecting information against unauthorized access. Governments have long restricted export of cryptography for fear that their intelligence activities are hampered by the crypto use of foreign states and scoundrels. Since the rise of crypto use over the past decades, governments increasingly worry about criminals using cryptography to thwart law enforcement. Thus, many countries have passed laws or are considering laws to maintain law-enforcement and national-security capabilities through regulation of cryptography.

 

This survey gives an overview of the current state of affairs, with entries per country on import/export controls, domestic laws, developments to restrict cryptography, and developments favoring crypto use. For more background on the crypto policy dilemma, see my Ph.D. thesis The Crypto Controversy. A Key Conflict in the Information Society (Kluwer Law International, 1999).

 

Cryptography used for digital signatures is not covered by this survey. For regulation of digital signatures, see Digital Signatures and Law.

 

In August 2001, the Norwegian government released their Norwegian Crypto Policy (Norsk kryptopolitikk, text in Norwegian). The policy in general takes a positive stance towards cryptography, arguing its value for securing data and for the economy. The policy declares itself against mandatory key-escrow, at least as far as individuals' use of cryptography for private purposes and authentication-only cryptography are concerned. Local mandatory key-escrow is, however, recommended for companies for internal use, because of the risk of data loss when a crypto key is lost. The policy also indicates that telecommunications service providers, including Internet access providers, can be required to provide plaintext to the government, if they are in possession of the plaintext or of the keys to produce the plaintext.

See also A basis for developing an integrated national crypto policy (text in Norwegian) by Lee Bygrave.

 

 

Mer kosmetikk enn realiteter.

 

BankID og noen digitale Ider er ganske sikre, men selv banker hackes. Jeg har hørt rykter om at banker har vært tappet for millioner, men i stedet for å fortelle åpent om det, dysses det ned. Tap av rykte kan være verre enn tap av noen millioner for en bank.

 

Merk at de som lager cURL ikke er noen nybegynnere. De vet selv det meste om hacking.

 

Haxx consultants do embedded programming, realtime, network and unix/Linux. We write device drivers, boot loaders and perl scripts with the same ease. We're not afraid to resort to assembler or touch the bare metal to get the job done. We are doers. We do what others only talk about.

Kilde: http://www.haxx.se/

 

Slutt med utenomsnakket og kom med reelle forslag til hvordan jeg kan forbedre sikkerheten på sitene mine, slik at de ikke tas ned. Jeg vil at det innholdet jeg lager skal være på nettet til jeg tar det ned.

Endret av Slettet+9871234
Lenke til kommentar
  • Hvorfor stiller du det spørsmålet?

 

det har som sagt med din uttalelse "Jeg får ta problemene den gang noen hacker seg inn i koden." å gjøre ...

 

nær sagt alt er forøvrig "innhold" og du spør hva du behøver frykte? at noen korrumperer innholdet ditt, selvsagt. medmindre det er totalt verdiløst.

 

Godnatt.

Endret av quantum
Lenke til kommentar
Gjest Slettet+9871234

det har som sagt med din uttalelse "Jeg får ta problemene den gang noen hacker seg inn i koden." å gjøre

 

Underforstått så lenge jeg ikke er i stand til å gjøre den sikrere enn med bruk av cURL. Ingen som poster i denne tråden har så langt gitt et eneste lite hint om å gjøre koden sikrere.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...