Magisk streng - Magic string

I dataprogrammering er en magisk streng en inngang som en programmerer mener aldri vil komme eksternt, og som aktiverer ellers skjult funksjonalitet. En bruker av dette programmet vil sannsynligvis komme med innspill som gir forventet respons i de fleste situasjoner. Imidlertid, hvis brukeren faktisk gir uskyldig den forhåndsdefinerte inngangen, og påkaller den interne funksjonaliteten, er programresponsen ofte ganske uventet for brukeren (og virker dermed "magisk").

Bakgrunn

Implementeringen av magiske strenger skyldes vanligvis tidsbegrensninger. En utvikler må finne en rask løsning i stedet for å gå dypere inn i et problem og finne en bedre løsning.

For eksempel når en tester et program som tar brukerens personlige opplysninger og verifiserer kredittkortnummeret, kan en utvikler bestemme seg for å legge til en snarvei med magisk streng, slik at den usannsynlige inndata av "***" som et kredittkortnummer vil føre til at programmet å fortsette automatisk som om kortet var gyldig, uten å bruke tid på å bekrefte det. Hvis utvikleren glemmer å fjerne den magiske strengen, og en bruker av det endelige programmet tilfeldigvis skriver inn "***" som et plassholderkredittkortnummer mens han fyller ut skjemaet, vil brukeren utilsiktet utløse den skjulte funksjonaliteten.

Vedtak

Situasjoner / årsaksspørsmål

Ofte er det betydelige tidsbegrensninger utenfor utviklerens kontroll helt fra begynnelsen av deres involvering i et prosjekt. Vanlige problemer som kan føre til dette antimønsteret som et resultat:

  • Null! = Null eller en hvilken som helst variant der en datatype ikke sammenlignes bitvis med en antatt identisk type. Dette er et problem som til og med kan forekomme i samme utviklingsmiljø (samme programmeringsspråk og kompilator). Dette problemet har en lang historie for numeriske og boolske typer, og de fleste kompilatorer håndterer dette godt (med gjeldende advarsler og feil, standardoppløsning osv ...). Nullable typer som strenger har vanskeligheten med historisk forskjellige definisjoner for NULL . Feilene / advarslene som er produsert er ofte generelle eller en "best fit" standardfeil hvis melding ikke egentlig beskriver hva som skjer. Hvis utvikleren ikke kan få nok ledetråder til å spore problemet gjennom feilsøking, kan det være en snarvei og koding i en 'standard' streng, den eneste måten å holde prosjektet på planen. En løsning på dette kan være anvendelsen av Null Object-mønsteret .
  • Programmert i et hjørne. Noen ganger virker en design grei og til og med enkel, men viser seg å ha en logisk feil, avhengig av mulige brukerinnganger, på grunn av en ofte uforutsett omstendighet mot slutten av planlagt utvikling. Dermed kan en utvikler føle behov for å implementere en brukerinngang med spesielle sikkerhets- / operasjonelle kvoter for å håndtere slike omstendigheter. Dette kan være spesielt ironisk siden det noen ganger vil bli åpenbart at en mer robust design fra begynnelsen sannsynligvis ville ha gitt rom til å håndtere feilen. Imidlertid ville dette ha tatt for lang tid å implementere, og det kan ha vært i konflikt med det grunnleggende tekniske konseptet til KISS , slik at design og implementering var enkel og kun oppfyller de første nødvendige kravene.
  • Tillater ekstern tilgang til et globalt flagg. Overtillit til at et globalt flagg aldri kan settes ved et uhell eller ondsinnet (ofte en ganske rimelig antagelse) rettferdiggjør slik implementering for testing og feilsøking, spesielt for små applikasjoner med enkle grensesnitt. Hvis distribusjonen av programmet er betydelig, er det imidlertid bare et spørsmål om tid før noen setter flagget. En åpenbar løsning er å aldri bruke en global variabel på en slik måte. En utvikler kan også gjøre flagget omstendig tilgjengelig. Så den magiske strengen i seg selv vil bli behandlet av programmet som alle andre innspill. Brukeren må deretter reprodusere innstillingen i tillegg til å produsere en samling andre hendelser som brukergrensesnittet diskret tillater, for flagget å akseptere innstillingen; et langt mer usannsynlig scenario, men fremdeles mulig.

Streng formatering

Å begrense formatet på inndata er en mulig vedlikeholdsløsning (bug fixing). I hovedsak betyr dette å validere inngangsinformasjon for å kontrollere at den er i riktig format, for å redusere muligheten for at den magiske strengen blir oppdaget av brukeren. Eksempler inkluderer validering av et telefonnummer for å sikre at det bare inneholder sifre (og muligens mellomrom og tegnsetting i begrenset grad) eller å sjekke at en persons navn har et fornavn og et etternavn (og er med store bokstaver). Det gjøres et unntak for den magiske strengen i valideringskoden, slik at den ikke blir avvist av validering. Det forventes at siden en bruker sannsynligvis raskt vil legge merke til den strenge håndhevelsen av formateringen, vil det sannsynligvis ikke oppstå for brukeren å prøve å legge inn en streng som ikke samsvarer med formatet. Derfor er det svært lite sannsynlig for brukeren å prøve den magiske strengen.

Som med alle inngangsvalideringsprosesser, er det viktig å sikre at formatet ikke er begrensende på en måte som utilsiktet begrenser bruken av applikasjonen til noen brukere. Et eksempel på dette er å begrense telefonnummer eller postnummerinngang basert på et lands system (for eksempel å kreve at hver bruker oppgir et femsifret postnummer ), og forårsake problemer for legitime brukere som er basert i andre land.

Målrettet implementering

Som det ofte er tilfellet med antimønstre, eksisterer det spesifikke scenarier der magiske strenger er en riktig løsning for en implementering. Eksempler inkluderer juksekoder og påskeegg . Videre er det tilfeller når brukere oppfinner magiske strenger, og systemer som ikke har kodet for å godta dem, kan gi uventede resultater som manglende lisensplater.

Se også

Referanser

  1. ^ Chris Falter (2008-03-06), A Good Solution for Magic String Data , "Egghead Cafe Tuturiols" på Egghead Cafe , hentet 11.05.2009 Ekstern lenke i |publisher= ( hjelp ) CS1 maint: motløs parameter ( lenke )
  2. ^ Frank Naude (06.12.2008), NULL , "Oracle Wiki" på Oracle Wiki , hentet 13.05.2009 Ekstern lenke i |publisher= ( hjelp ) CS1 maint: motløs parameter ( lenke )
  3. ^ Wang Lam (2003-05-21), atferden til NULL er i SQL , "Stanford University" på Stanford InfoLab , hentet 2009-05-13 Ekstern lenke i |publisher= ( hjelp ) CS1 maint: motløs parameter ( lenke )
  4. ^ Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates; 2004, Head First Design Patterns , 1. utgave, O'Reilly, kapittel 6, s. 214, kommandomønsteret , ISBN   0-596-00712-4 , ISBN   978-0-596-00712-6
  5. ^ James McCaffrey (2009), Testautomatisering for ASP.NET Web Apps med SSL , "Microsoft" på MSDN , hentet 2009-05-13 Ekstern lenke i |publisher= ( hjelp ) CS1 maint: motløs parameter ( lenke )
  6. ^ Andrew Cumming; 2007, SQL Hacks , 1. utg., O'Reilly, s. 174, Prevent an SQL Injection Attack , ISBN   0-596-52799-3 , ISBN   978-0-596-52799-0
  7. ^ Brian Knight, Allan Mitchell, Darren Green, Douglas Hinson, Kathi Kellenberger; 2005, Professional SQL server 2005 integration services , 1. utg., John Wiley and Sons, kapittel 5, s. 129, Håndtering av skitne data , ISBN   0-7645-8435-9 , ISBN   978-0-7645-8435-0
  8. ^ Sezen, Tonguc Ibrahim; Isikoglu, Digdem (2007-04-27). "FRA OZANER TIL GUD-MODUSER: FUSSING I INTERAKTIV UNDERHOLDNING FRA FORSKJELLIGE KULTURER" (PDF) : 8 . Hentet 24-01-2009 . Sitatjournal krever |journal= ( hjelp ) CS1 maint: motløs parameter ( lenke )
  9. ^ https://www.snopes.com/autos/law/noplate.asp