Re: Pass hard coded param CGI post

in reply to Pass hard coded param CGI post

>"hard coded"

Back in my day, we called these hidden form elements.

<form action="/cgi-bin/delete.pl" method="POST" accept-charset="UTF-8"
+>
  <div class="form-group">
    <label for="id">&nbsp;Your token</label> 
    <input id="id" name="token" type="text" class="form-control" reado
+nly >
  </div>
  <div class="form-group">
   <input type="hidden" name="key" value="gfgf">
   <input type="hidden" name="usr" value="rob">
   <button name="submit" type="submit" class="btn btn-primary">Delete<
+/button>
  </div>
</form>
[download]

Fortunately, we've learned a few things since then, like:

Send values via method=POST so you don't broadcast your values in the action URL even when using SSL/TLS
.cgi is a pain to maintain (use Dancer2 or Mojo)
this pattern of HTML form + cgi processor is inferior to using a modern JavaScript async call to send the data to a RESTful API endpoint (like /cgi-bin/rob/gfgf with method=DELETE, encoded as application/json

To answer your question about what is happening? The browser is resetting the query part of your action (when method=GET, adding only the named form elements to the call to action and stupidly dropping what's in there. I am sure I had actions with query params in them once upon a time, and I don't recall the query string being fully replaced. But in any case, that's what's happening. I bet if you set method=POST and kept that action it would retain your query params. But use the <input type="hidden"..., that's what it's for.

Comment on Re: Pass hard coded param CGI post Select or Download Code

Replies are listed 'Best First'.
Re^2: Pass hard coded param CGI post by jcb (Parson) on Jun 29, 2020 at 23:42 UTC
this pattern of HTML form + cgi processor is inferior to using a modern JavaScript async call to send the data to a RESTful API endpoint (like /cgi-bin/rob/gfgf with method=DELETE, encoded as application/json I do have to stop and take issue with this. A key principle on the Web is graceful degradation. Nearly all interactive browsers support forms, including such oddballs as Lynx and other curses-based browsers that do not require a graphical display. You can have a fancy JavaScript frontend, but you should still have basic forms — perhaps the CGI form processor translates the form submission to a RESTful request — for browsers that do not support JavaScript and users that choose not to run JavaScript. That last note *is a legitimate choice* no matter how many hipster Web developers whine about it — nearly all client-side Web security exploits in the modern era have depended 100% on JavaScript to run. Disabling JavaScript is very much legitimate security advice, unless of course you want your files ransomwared.	[reply]
Re^3: Pass hard coded param CGI post by Anonymous Monk on Jun 30, 2020 at 01:19 UTC
nearly all client-side Web security exploits in the modern era have depended 100% on JavaScript to run^{[citation needed]}	[reply]
Re^4: Pass hard coded param CGI post by jcb (Parson) on Jun 30, 2020 at 02:20 UTC
Then provide some counterexamples. Even Internet Explorer (as far as I know, the only browser to ever be exploitable with only plain HTML) had those problems only in the late 1990s. All of the recent exploits I remember off the top of my head have been JavaScript JIT bugs.	[reply]
Re^5: Pass hard coded param CGI post by Your Mother (Archbishop) on Jun 30, 2020 at 08:32 UTC
Re^2: Pass hard coded param CGI post by Anonymous Monk on Jun 29, 2020 at 01:21 UTC
Thank you for your help. Also thank you for the suggestions. I am writing a really basic application, so I ended up using the old CGI and HTML::Template. I am on a shared server which does not allow too much. It comes with CGI enabled and I think installing and using the Mojolicious framework is not possible. I had a look at the framework, and it seems to me that it would need quite an investment in time to set it up and learn it. I would be ready to use some Mojo modules to replace CGI. However, I could not find any way to perform in Mojo the same basic things I am doing in CGI, so to say, out of the box. Am I wrong?	[reply]
Re^3: Pass hard coded param CGI post by haukex (Archbishop) on Jun 29, 2020 at 15:09 UTC
I am on a shared server which does not allow too much. It comes with CGI enabled and I think installing and using the Mojolicious framework is not possible. Yes, even you can use CPAN - Mojolicious is pure-Perl, with no non-core dependencies, which makes it especially suitable for installing in situations like these. I had a look at the framework, and it seems to me that it would need quite an investment in time to set it up and learn it. Well, for really simple CGI applications, sure, you could use e.g. CGI::Simple. But I've been using Mojolicious more and more recently, and I think it's good even for really simple stuff, and IMHO learning it is definitely worth the investment because you'll get so much more functionality out of a seemingly simple app. To get started, have a look at Mojolicious::Guides::Tutorial. I also have several examples on my scratchpad. However, I could not find any way to perform in Mojo the same basic things I am doing in CGI, so to say, out of the box. This is the equivalent to the code you showed: #!/usr/bin/perl use Mojolicious::Lite -signatures; get '/' => sub ($c) { $c->render(template => 'index'); } => 'index'; get '/delete' => sub ($c) { my $token = $c->param('token'); my $key = $c->param('key'); my $usr = $c->param('usr'); $c->render( text=>"Token: $token - Key: $key - Usr: $usr" ); } => 'delete'; app->start; __DATA__ @@ layouts/main.html.ep <!DOCTYPE html> <html> <head><title><%= title %></title></head> <body> %= content </body> </html> @@ index.html.ep % layout 'main', title => 'Hello, World!'; <div> %= form_for delete => ( method=>'get' ) => begin %= hidden_field key => 'gfgf' %= hidden_field usr => 'rob' <div class="form-group"> %= label_for id => 'Your token' %= text_field token=>'Default', class=>"form-control", id=>"id", r +eadonly=>undef </div> <div class="form-group"> %= submit_button 'Delete', class=>"btn btn-primary" </div> %= end </div> [download] Though you should probably change `get '/delete'` to `post '/delete'` and `method=>'get'` to `method=>'post'`. This script will work both when started via e.g. `morbo script.pl`, and as a CGI script automatically.	[reply] [d/l] [select]
Re^3: Pass hard coded param CGI post by perlfan (Vicar) on Jun 29, 2020 at 05:39 UTC
>Am I wrong? I am not super familiar with Mojo. And I do not think you're wrong. But you can use something like CGI::Application in your .cgi right away so that you can start organizing your code for a more "modern" paradigm. With some fiddling of the apache configuration (assuming), you can look at using actual routes via CGI::Application::Dispatch. It is true and relevant that changing your mindset is probably the hardest thing to do overall. I can see how on a shared hosting system where you don't have access apache configurations or to determine what is listening on port 80/443, that you would have the very real limitations you're describing. Go with what you know, but know that even in your environment you have some options.	[reply]
Re^2: Pass hard coded param CGI post by Anonymous Monk on Jun 29, 2020 at 06:33 UTC
perlfan:.cgi is a pain to maintain (use Dancer2 or Mojo) silly statement as both mojo.cgi and dancer.cgi are both .cgi	[reply]
Re^3: Pass hard coded param CGI post by perlfan (Vicar) on Jun 29, 2020 at 14:50 UTC
Care to explain the nuance or technicality you're using to sully my helpful and informative answer? I think in the context, it's clear what I am talking about.	[reply]
Re^4: Pass hard coded param CGI post by Anonymous Monk on Jun 30, 2020 at 01:36 UTC
Care to explain the nuance or technicality you're using to sully my helpful and informative answer? I think in the context, it's clear what I am talking about. It is clear the statement is not valid, no nuances required.	[reply]

In Section Seekers of Perl Wisdom