Run a variable as code?

Hey all :smiley:
Is it possible to run a variable as pure applescript code?
Something like:


set someCode to "beep 3"
run someCode

I need it because I am making a thing where applescript can be run from the web, I have already got the ā€œrunthiscode://foreign code hereā€ part working and it sets whatever is after ā€œ://ā€ to a variable but how can I run it after that?
Here is what I have so far


set keepLoop to true
on open location localURL
	set oldDelims to AppleScript's text item delimiters
	set AppleScript's text item delimiters to "openfromurl://"
	set doThis to item 2 of the text items of localURL
	set AppleScript's text item delimiters to oldDelims
	
	repeat until keepLoop is false
		tell application "Safari"
			beep
			set askD to display dialog "This site is trying to run code on your computer, do you want to allow this?" buttons {"Don't Run", "View Code", "Run"} with icon 2
			if button returned of askD is "View Code" then
				display alert "Code:" message " " & doThis
			end if
			if button returned of askD is "Run" then
				(* What to do here *)
			end if
			if button returned of askD is "Don't Run" then
				keepLoop = false
				display dialog "Execution Of Code Stopped" with icon 1 giving up after 1.5 buttons {"Close"}
			end if
			
		end tell
	end repeat
	
end open location

thanks in advance :smiley:

Hi,

You could use ā€˜run scriptā€™.

set someCode to "beep 3"
run script someCode

John M

Astoundingly bad idea. Google ā€œcode injectionā€ to learn what happens when sloppy web developers do this accidentally.

If you want to control your Mac remotely, use ssh or vnc and secure, hard-to-crack passwords.

set doThis to text item 2 of localURL

set askD to button returned of 

set keepLoop to false

Ditto.

Reading between the lines, or rather between the posts, Captainhams (of this thread) is apparently trying to help fabiolr (of the thread ā€œUsing a Widget as an AppleScript UIā€) to integrate a widget with local AppleScript function. Captainhams may have mistakenly asked about use via the web, with a browser, because the methodology heā€™s pursuing could potentially work in either widget or browser.

If Iā€™m wrong and Captainhams is actually looking for web operability, then I concur: very bad idea.

If his project is restricted to Dashboardā€™s local ā€˜sandboxā€™ and implemented properly, I donā€™t see the risk or harm.

I believe I could (probably) adapt Missing Link to perform only the function that fabiolr seeks, but I would only offer it in run-only form to a mass audienceā€¦ and not being otherwise employed, Iā€™d have to exact a fee for the effort.

2 Cents.

Or ratherā€¦ something more than 2 cents.

Peter B.


Please explain the reason underlining the conclusion that this is a really bad idea? :expressionless:
It asks if the code is to be run or not, and with the option view what is going to get rrun.
But thanks for the feedback!

Captainhams:

You deserve an answer, even though I donā€™t feel qualified to provide a complete one.

What I can tell you from my own experience trying to promote a similar schema is that - pretty much regardless of potential merit - you will likely find few takers in the Mac community for your idea.

I think the core fear is that if your approach were implemented by many, the potential for abuse (particularly through ā€˜social engineeringā€™) would be enormous. A simple ā€œdonā€™t worry about itā€ exhortation to click through a ā€˜run/donā€™t runā€™ dialog would be plenty enough for some to go ahead and launch a malicious (or malformed) script that could render the userā€™s computer unusableā€¦ a magnanimous gift from an anonymous website.

I actually find the AppleScript protocol used here in this forum somewhat suspect for the same reason, even though it was created by Apple and has their explicit blessing. But there are few visitors even here that can appreciate all the subtleties of (e.g.) an obfuscated AppleScript or shell script. Even here, the only defense against calamity is ā€˜trustā€™. Click ā€˜Runā€™ in Script Editor, and itā€™s over.

Generally, even though Missing Link was never intended for anything but local use, it has been either roundly ignored or roundly condemned over a lifespan of several years. Fairly recently, I fielded a version that I think might (finally) be of genuine utilityā€¦ yet ML still refuses to ā€˜flyā€™.

Maybe others will chime in with other reasons why this is not a great ideaā€¦ but Iā€™ll stress that there ARE security implications involvedā€¦ and they should not be casually overlooked.

Peter B.


While I agree with you Peter that the AppleScript link is of the same ilk as any other Missing Link you might propose, the difference is that the AppleScript link has to be ā€œempoweredā€ on the server, and is generally used only in sites like MacScripter (which uses a modified version with less formatting to make it faster and save cpu time on the server). And you do have to give permission the first time you download a script, and thereafter have to run it yourself. I myself have never used Missing Link because I donā€™t have a need ā€“ I donā€™t run a server.

Everything on the Internet should be suspect.

Digressing entirely from the original post nowā€¦

Missing Link does not require a server. Thatā€™s at least half the point. It stands alone and does a (small) variety of things a server doesā€¦ locally.

Agreedā€¦ adds weight to the argument for a local solution.

I will bow out gracelessly now, and get on about me own bizness.

Peter B.


Dancing in traffic isnā€™t guaranteed to get you run over, it just increases the risk by a foolish amount.

If suggest you post a description of what it is youā€™re trying to achieve, and perhaps folks can advise you on a safe way to do it. e.g. If you want to control your Mac remotely, or you want to create a web interface for your favourite desktop application, there are safe ways of doing these things.