CGI, without going anywhere?

[MattEvans]

When I was learning the basics of Perl CGI (well, any CGI) I vaugely remember something regarding a header or command that would invoke CGI script (using a standard GET request) WITHOUT changing the page that a user was on.

Googling hasn't been fruitful, I only remember a brief mention, and maybe it wasn't exactly what I'm thinking...

I can get around it, but it'll involve editing more than one document >_< I guess (for more than one reason) that it'd be a good idea to edit those documents anyway.

But; does anyone know what this mystical line is? or if it even exists?

[KevinADC]

Maybe some trick involving frames or an iframe?

[MattEvans]

Eww >_< i'll pass that up. I suppose I could launch a new window aswell; but that's going against what I want rather than towards it. Maybe it could work though...

I think using the referer address and going back there might be a better method though. Is there an automatically-available (environment) way to access that reliably? But I suppose that'd suck if a user bookmarked the CGI script.

It's gonna be referer-by-query-string methinks, and it's GOTTA be deeper than javascript O_o.

Thanks anyway,

Matt

[KevinADC]

When I was learning the basics of Perl CGI (well, any CGI) I vaugely remember something regarding a header or command that would invoke CGI script (using a standard GET request) WITHOUT changing the page that a user was on.

I think you might be refering to non-parsed header scripts. I am not familiar with writing them or using them but you can probably do a google search for no-parsed header and see if you find anything useful. I know the CGI module does support NPH scripts so you mihgt want to look up the CGI documentation as well.

[sut]

Are you saying you don't want to grab any output, you only want to execute the CGI?
For that you could put the URL in a button.

If you want to dynamically change a part of the page without editing then you might be wanting server-side scripting such as with shtml. You need to make sure your server is configured for that.

[MattEvans]

Mm, this was/is the desired context:

- user clicks on login button,
- page refreshes with the user logged in.

and this was the actual context:

- user clicks on login button,
- page changes as the script that verifies the user executes
- user hits back button
- user hits refresh a few times
- user is logged in

This is how it goes now:

- user clicks login button
- page changes as the script executes
- page is refeshed after two seconds (meta refresh) to the previous page (passed via a query string)
- user is logged in

I still love the first context, but for now, seems to be ok. Although, it sometimes takes more than one refresh for the page to correctly update o_O. I was using SSI to get the userstate information, now I'm using CGI-generated XML through-XSLT, and I know some cachings going on somewhere undesired! I may go back to the SSI option for deriving the present userstate. Dunno!

Thanks though, I will certainly aim for it to be the first way!

I suppose what i want to do is:

- user clicks login button
- script executes silently
- page refreshes
- user is logged in

I also don't want JavaScript to be required. So the only thing to play with is GET/POST form actions, the CGI itself, and what can be deemed as a "standard" HTML page.

Matt

[KevinADC]

I suppose what i want to do is:

- user clicks login button
- script executes silently
- page refreshes
- user is logged in

Since that is not normal CGI behavior I would suggest against it. Most people expect whan they click a form button something will happen pretty much right away. If it doesn't they will probably click the button again or hit refresh, which might defeat the purpose of what you intend. You may have good reason for what you want to do, but using a CGI form might not be the best way to go about it.

[vonfeldt]

i'm still not quite sure i know what you are after... is your user filling in username and password fields that you want to retain after hitting a button?
seems easy enough. is there other content that is based on the users credentials? are there links on the page that are limited that are to be active after login?

it's late. i'm tired. maybe Kevin is right and it should be done some other way...

[sut]

I would seriously recommend losing the "no javascript" rule. Then you could do a nice controlled, visually acceptible refresh.

Otherwise, non-parsed header scripting is the way to go.

Just prefix the script with "nph-"

#!/usr/bin/perl
print "$ENV{'SERVER_PROTOCOL'} 204 No Content\n";
print "Server: $ENV{'SERVER_SOFTWARE'}\n";
print "Content-type: text/plain\n\n";
# put your log on code here
exit(0);

Of course you could also

#!/usr/bin/perl

print "Content-type: text/plain\n\n";
print "<META HTTP-EQUIV=\"Refresh\" CONTENT=\"1; URL=http://yourhost/yourpage.html\">\n"

[sut]

Sorry, I got in a big hurry to leave yesterday and got careless.

Of course you could also

#!/usr/bin/perl

print "Content-type: text/plain\n\n";
print "<META HTTP-EQUIV=\"Refresh\" CONTENT=\"1; URL=http://yourhost/yourpage.html\">\n"

What I wanted to write was:

#!/usr/bin/perl
 
 print "Content-type: text/[B]html[/B]\n\n";
 print "<META HTTP-EQUIV=\"Refresh\" CONTENT=\"1; URL=http://yourhost/yourpage.html\">\n"
[B]# put your log on code here[/B]

[MattEvans]

I suppose what i want to do is:

- user clicks login button
- script executes silently
- page refreshes
- user is logged in

Since that is not normal CGI behavior I would suggest against it. Most people expect whan they click a form button something will happen pretty much right away. If it doesn't they will probably click the button again or hit refresh, which might defeat the purpose of what you intend. You may have good reason for what you want to do, but using a CGI form might not be the best way to go about it.

You're right! I've changed my methods somewhat, and all my pages are processed by a CGI script. A side effect of that is that now I can pass GET/POST requests through the current page; making it possible to cut out the good old "Logging In..." interim page.

But, it's veeery unsatisfactory, if the user clicks "Back" the page resends the query; and it has to be a POST query. So that results in a sucky "The page cannot be refreshed without resending information" type error, and that can potentially occur on any page (i.e. index.html)

It was a nice idea; but I'll go back to my "Logging In.... Click here if you're stuck here" page. Think I might be able to get around the referer query parameter now though.. ;)

[MattEvans]

Wahey... I have got it working how I originally wanted without the problem I just mentioned..

It doesn't seem conventional certainly.. And there is a potential risk of the user hitting Refresh while the login script is executing, which I guess would abort the script... Although; does a script get killed if it's started processing and the user agent leaves it?