Setting up a web-based perl interpeter

sulfericacid has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Setting up a web-based perl interpeter by marto (Cardinal) on May 27, 2011 at 15:25 UTC
Regarding codepad.org being down, I google searched for some alternatives and found http://ideone.com/, among others.	[reply]
Re^2: Setting up a web-based perl interpeter by Anonymous Monk on May 27, 2011 at 16:37 UTC
I haven't seen others but the one you posted I just checked out. That is loaded packed full of ads. My sys admin/sec team would not appreciate loading a page that has that much activity on it. They might all be that way, I haven't used any of these before but it is a neat idea. I know I probably couldn't be loading a page like this one in my environment without some flags being raised. Especially if it takes numerous pastes or reloads to get a script to work properly.	[reply]
Re^3: Setting up a web-based perl interpeter by marto (Cardinal) on May 27, 2011 at 16:45 UTC
"My sys admin/sec team would not appreciate loading a page that has that much activity on it." If you mean browsing install adblock (or similar). I wasn't suggesting you use this sites design as a basis for your own. You could setup whatever UI you're comfortable with.	[reply]
Re: Setting up a web-based perl interpeter by wfsp (Abbot) on May 27, 2011 at 15:24 UTC
Does your web hosting account include SSH access? I use Putty to log on to my webhoster and am able to write and run Perl scripts (and much else). I get to fight with the mighty vim into the bargain. :-) If your hoster doesn't provide SSH access it may be worth getting one that does. HTH. update: What tospo said. You have to be quick off the mark round here. :-)	[reply]
Re: Setting up a web-based perl interpeter by anonymized user 468275 (Curate) on May 27, 2011 at 15:06 UTC
If it's a nix server environment, you could spawn something like `file.pl > file.out 2> file.err` [download] and provide site navigation to those files One world, one people*	[reply] [d/l]
Re: Setting up a web-based perl interpeter by tospo (Hermit) on May 27, 2011 at 15:18 UTC
First I thought you wanted to make available an interactive Perl shell for public use, which would be nice. Something like that exists for Ruby so people can try out some code before they actually install anything locally. But if this is only for your own use, what would be the benefit over just logging into your remote machine with SSH and do all you need to do with Perl that way?	[reply]
Re^2: Setting up a web-based perl interpeter by sulfericacid (Deacon) on May 27, 2011 at 15:24 UTC
I can't say it's not possible it'd be public once I worked out all the bugs and got the OK from the good people at HostGator but essentially I don't want to do any SSH or logins of any time. I could simply log into my cpanel and upload Perl files that way but I don't want to have to authenticate in order to test out code. Having my browser tab open to the interpeter form would work in the environment in now and ANY job I have in the future without Perl available. "Age is nothing more than an inaccurate number bestowed upon us at birth as just another means for others to judge and classify us" sulfericacid	[reply]
Re^3: Setting up a web-based perl interpeter by tospo (Hermit) on May 27, 2011 at 17:01 UTC
but if you don't want to do any SSH into the remote machine, how would you do your "admin stuff" like installing new modules? I can imagine that debugging will also not be much fun with this webapp. And then of course there are all those security concerns. Maybe you would be better off just bringing your laptop to work... :)	[reply]
Re: Setting up a web-based perl interpeter by davido (Cardinal) on May 27, 2011 at 16:07 UTC
Have you considered the issues regarding security? Security through obscurity (not publishing the URL) is not security. URL's can be discovered eventually. You could require a login, but you mentioned you're opposed to that approach. If you disable the use of all modules via disabling 'use', 'require', and 'do', the use of all system commands (including open), the backtick and qx// operators, the s///e construct, eval, you have suddenly created a huge project, and one that doesn't even touch the tip of the iceberg with respect to preventing malicious attacks. I know that most of the simple attacks can be prevented, but when you expose the interpreter to the world, you have to be sure you thought of every possible attack. Dave	[reply]
Re^2: Setting up a web-based perl interpeter by SuicideJunkie (Vicar) on May 27, 2011 at 16:25 UTC
How about running the untrusted code on a virtual machine that lacks a network connection, and can be restored to a good snapshot between sessions or after a timeout?	[reply]
Re^2: Setting up a web-based perl interpeter by Anonymous Monk on May 27, 2011 at 16:29 UTC
That's not true. Not publishing a URL can be quite secure. If the OP doesn't ever publish it somewhere and nests the directory tree 3 or more directories deep with charactor-random directory names no one and no bot will ever find it. Ie: somesite.com/234sfsd/zzasdf21/ooiissa221/22234AZa/pwa2r.pl That obscurity it absolutely security. The OP could go one or two steps further by not having the script run unless a certain param is passed to ie, ie: pwa2r.pl?mode=a23da. Now there is a level of authentication with an obscure URL. The other step is doing an IP-based security if they have a static IP address. Any one of those tiers of security is not completely secure by itself but if two or more of them are used you have yourself a very secure script without the need of authentication.	[reply]
Re^3: Setting up a web-based perl interpeter by Your Mother (Archbishop) on May 27, 2011 at 16:42 UTC
Unless any part of the served pages ever, at any time, calls an external URL or visits one from it. Plus IP filtering is a form of authentication and, without reverse look-ups, not a "very secure" one.	[reply]
Re^4: Setting up a web-based perl interpeter by Anonymous Monk on May 27, 2011 at 16:52 UTC
Re^5: Setting up a web-based perl interpeter by Your Mother (Archbishop) on May 27, 2011 at 18:24 UTC
Re^5: Setting up a web-based perl interpeter by MidLifeXis (Monsignor) on May 31, 2011 at 12:58 UTC
Re^3: Setting up a web-based perl interpeter by flexvault (Monsignor) on May 27, 2011 at 18:29 UTC
That's not true. Not publishing a URL can be quite secure.... If you're using a web server, people will be knocking on your server port within hours. In the 90s you could put a server up and no one tried for weeks, after 2001 it was less then 8 hours and now about 2-4 hours. If you use https with your own certificates, you may have a chance. But, that's a lot of work! Further, on the "...script run unless a certain param is passed...", that param had better change every few minutes, or you'll find someone harvesting your information. A recent study of victims of on-line theft stated that 95% of them thought they didn't have anything to steal on their PC. Now add a web server! Go with security first! "Well done is better than well said." - Benjamin Franklin	[reply]
Re^4: Setting up a web-based perl interpeter by Your Mother (Archbishop) on May 27, 2011 at 18:37 UTC
Re^3: Setting up a web-based perl interpeter by MidLifeXis (Monsignor) on May 27, 2011 at 20:17 UTC
Does your traffic pass through something I have control over? Think network, cache, diverted network route, wireless leak, ... --MidLifeXis	[reply]
Re^3: Setting up a web-based perl interpeter by Anonymous Monk on May 27, 2011 at 16:30 UTC
I did forget the add the OP would have to have an index file in the above mentioned directories so the tree isn't visible.	[reply]
Re: Setting up a web-based perl interpeter by Your Mother (Archbishop) on May 27, 2011 at 16:34 UTC
What davido++ said. Of interest: Safe.	[reply]
Re: Setting up a web-based perl interpeter by ww (Archbishop) on May 27, 2011 at 16:39 UTC
"I switched jobs to a company that doesn't have/allow Perl to be installed. I still want to be able to do this ...." Never mind that the antecedent of "this" is undefined; one can infer, from context, that it stands for "code in Perl" or words to that effect. But from your new company (office, cube, whatever)? When the employer expects you to be working... according to its standards? /Methinks you'd be wiser to write prototypes or whatever either with their specific blessing (does the "have/allow" construct mean you don't know if the issue is merely "doesn't have" as opposed to "forbids" or that the company's posture makes both verboten?) or ... on your own time in your own place/	[reply]
Re^2: Setting up a web-based perl interpeter by Argel (Prior) on May 27, 2011 at 17:14 UTC
Very good points. It's a bad idea, period. Either he will be doing personal stuff, or he will be doing company related work over the Internet to his PC. Pasting in company data to process over the Internet? Could be a firing offense. Just like SSHing could be as well. More likely he will just get in trouble for it, but getting in trouble after just starting a new job doesn't sound very smart and could increase the odds of getting fired. Elda Taluta; Sarks Sark; Ark Arks	[reply]
Re: Setting up a web-based perl interpeter by flexvault (Monsignor) on May 27, 2011 at 15:24 UTC
eval will help on the "crashing", and < pre >...< /pre> will help you get the results. But you may have to search on special characters. ( Note: big one is '&'. ) Perl can do it! But you may want to educate your new bosses about the value of perl as a prototype tool. Good Luck! "Well done is better than well said." - Benjamin Franklin	[reply]


Welcome to the Monastery
	PerlMonks