Url encoding og GET / POST

hvis der i din form står
action="POST" så kan man ikke se dem i url'en...

Der er ikke så meget eksempel, at hente.. lav en form og submit den med nogle værdier..

prøv først med

<form action="POST" ...

og bagefter

<form action="GET"  ...

ja det mente jeg også...probelmet er bare, at det ikke ændrer noget her?
Jeg benytter masterpages og content page og det er jo i masterpagen jeg har sat:

<form id="form1" runat="server" method="post">

du vil gerne have GET fra en side der arver fra den?

forstår ikke helt hvad du mener... Jeg vil blot sende en variabel fra en content page til en anden...UDEN at indholdet af variablen vises i url'en...

jeg kunne selvfølgelig også bare bruge appSetting til at gemme og tilgå data eller session...det behøves jo ikke sendes direkte til siden...det vigtigeste er jo  blot at data er tilgængelig når man skal bruge det...

Hvad er jeres holdning?

Jeg plejer ikke at placere min form i masterpagen selv:)

Angående dit eget forslag.... så kræver det jo postback.. men det er måske i orden?

er dit problem bare at du ikke får fat i dine variabler?

- har nemlig 2 forslag.

Et benyt

Request[""]
og ikke
Request.QueryString / Form

og hvis det er asp controller du skal have fat i kan du benytte

PreviousPage.

men hvis post back er i orden så måske hellere gemme i hidden fields frem for web.config.

du kan lige se om det andet jeg skrev var brugbart

Jeg kan sagtens få det til at virke med almindelig "Cross Page Posting" via url encoding...men der kan man jo se data, hvilket ikke duer...

Jeg kan kan også vælge session eller appSettings eller ja et hiddenfield...

Det vigtigste er blot at brugeren ligemeget hvad IKKE kan se eller tilgå data som sendes...så ved ikke hvilken metode som er bedst?

Kan ikke huske hvordan man bruger hiddenfield så jeg kan tilgå data fra begge sider af, kan du vise mig det? Er det ikke den bedste måde? hvis man også tænker på server load mv...?

As with any other Web server control, the information in a HiddenField control is available during postback. The information is not persisted outside the page.

HiddenField Control and Security
The information in a HiddenField control is not displayed when the browser renders the page, but users can see the contents of the control by viewing the page's source. Therefore, do not store sensitive information in a HiddenField control, such as user IDs, passwords, or credit card information.

Så hiddenfield er altså ikke løsningen til sikker "Cross page posting"...er der så kun session tilbage...?

jeg har ikke tjekket og API'et har det indbygget..har det vel, men ellers kan du encrypte og decrypte via. disse metode

http://www.devx.com/webdev/Article/30811/1954?pf=true

nederst på siden er der et .NET eksempel hvor det anvendes

et mere
http://www.codeproject.com/aspnet/URLRewriter.asp

og ellers tjek lige

Server. objektet igennem om det ikke indeholder noget brugbart.

yes ok...et sidste spg... er det "forkert" er bruge: ConfigurationManager.AppSettings
til at sende data i som sendes via "Cross page posting"?

Jeg benytter kun web.config til, at gemme indstillinger eller værdier der kan ændre sig efter noget tid.. f.eks email opsætning og sådan nogle ting.

Til det du har tænkt dig har jeg aldrig benyttet den:D

(så ville jeg hellere benytte Session hvis du altså kunne det)

ok, super...session data er jo heller ikke tilgængelig for brugeren via view source eller lign. vel?

Nej det er den ikke:)

så er der vel i grunden ikke behov for kryptering...eller kan en hacker mon fikse den uden probs?

Bare læg et svar! :)

den jeg vidste før ja for han kan nok godt se hvad den er encoded med:P

hehe - mange tak hjælpen!

jeg lavede engang til noget lignende hvor data ikke skulle igennem browser en webservice hvor data sendes igennem dem til en server hvor der her blev hold styr på hvilken data der tilhørte dig ud fra en GUID.. det blev altså gemt i en DB.

Det betød så at jeg skulle kalde webservicen fra en anden side med den GUID, som er gemt i session objektet for at få data'en.

men jeg benyttede også POST oven i det hele..

Det betyder så også at der skal arbejdes lidt meget med databasen.. men det virkede godt:)

okey...det er også kun for at være super sikker...pga. jeg også blot overfører et guid...bare med session...og derefter kører den også med webservice til db ;)

og ja...jeg kan hurtig kryptere data i session objektet og komm. mellem webservice og db...så det skulle blive rimelig sikker...

og ja hvis jeg har tid en dag kan jo også rode med url rewriting...men det virker lidt indviklet pt...