Welcome!
This is the community forum for my apps Pythonista and Editorial.
For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.
Delete Module
-
Do I remove a module in Pythonista? So I can't import it anymore. I mean, in the app, not in the template.
-
Why would you want to delete a module? If you don't want to use it, just don't import it in the first place
-
I just want to get rid of the webbrowser module completely. So it is not on the app anymore.
-
Why? It wont ever run as long as you don't import it.
-
I want to remove it from the app. I want to delete webbrowser.py. I want to never be able to import webbrowser again, not only in the same program, but appwide.
-
As Lukas already asked: why? Why do you want to do this?
-
It would help to understand the motivation (for instance, you are trying to use this in a classroom, and don't want students just surfing the web. or, on full moon nights you transform into your alter ego which likes to program in python while watching cat videos)
For basic "removal" of webbrowser.py, the best you can do is create a dummy webbrowser.py in site packages that blocks importing of the real one:
Here is such a modified webbrowser.py:
#coding = utf-8 raise ImportErrorThen, to help fool your cat video watching alter ego, you could try, from the console:
os.chmod('site-packages/webbrowser.py',0o100444)
though of course this could be easily undone (though we'll make your cat lover work for the answer by not mentioning it here). I also won't mention at least two other ways one could still run the original file.Since webbrowser is written using the ui module's WebView, really you would need to lock down ui as well(create a wrapper for ui.py that hides WebView, and lock down ui.py as above). if your students or cat vid loving persona are really resourceful, you should lock down urllib, urllib2, urllib3, objc_util, and probably many others.
-
As @JonB said, it's really hard to fully block access to a specific module or feature. Most restrictions written in Python can be easily undone with enough effort, and as long as
ctypesand such are accessible you can do much worse things than opening a web browser anyway. Pythonista isn't meant to be sandboxed, though if you want to use it for teaching or something, you can probably come up with a solution that works well enough (depends on the age of who you are teaching and how skilled they are of course). But without knowing your use case it's hard to say what would be the best solution. -
I am teaching a classroom full of 14 year olds; their skill set might surprise you.
-
They still could use the
uimodule to build their own web browser.
It'd take only 3 lines. -
So making a dummy webbrowser, locking it using os.chmod would slow down a few users.
If you had it mock webbrowser, but instead of opening urls, have it play a loud sound, or send you an email that user xxxx tried to access site yyy... that way at least until they figure out what you did, you will know who is trying to play games.I suppose if one were to create custom modules which overrode:
os.chmod
builtin's import
sys (to hide the c modules, prevent changes to path, maybe prevent access to current frame)
ctypes, objc
shutil(?)
importlib
pdb
ui
tcplib
socket
and maybe a few others, it might be possible to create a sort of sandboxed pythonista. At least make it reasonably hard, and if a kid can figure out how to bypass, then he deserves to surf the web, since your class maybe too easy for him/her.i am sort of both tempted and afraid to try such a lockdown... lest it actually work.
A better option would be to turn off Wifi alltogether on the device, and enable Guided Access in pythonista. This will prevent your students from leaving pythonista, or reenabling wifi. Presumably you don't want them leaving the app and launching safari anyway?
-
I also don't how much you are trying to restrict your students. But if it's only within Pythonista for example, maybe in the future @omz could add some preference settings that could help you build your own solution. For example a bottle server you make that the student has to log into to retrieve the assignment and with some API
Key style arrangement was able to alter what was available to the students from within Pythonista. Of course the ability to do a hard reset locally, but if a hard reset done it could be recorded securely in Pythonista and requested by your bottle app next time the student logs in.
Anyway, I thought Pythonista should have an API_Key anyway as things like workingcopy has etc.Anyway, this doesn't help you right now. And maybe my idea is crap (Just an idea to spark other ideas) . But I can see how some supporting classroom features would be very beneficial for Pythonista .
-
The real issue is that you can often escape sandboxes written in Python by catching an exception coming from a sandboxed function, and then using its traceback object to access the stack frames of the sandbox function, whose locals contain the unprotected versions of the built-in function that you're trying to hide.
There's also the issue that you can quite easily crash any Python runtime by constructing a
codeobject containing invalid bytecode. I assume you're using the iOS "guided access" feature (or whatever it's called) to lock your students down to just Pythonista, and I'm not sure what it does when the locked app crashes. -
@dgelessus I tried Guided Access, and when you crash the app, it immediately launches it again. Also, things like webbrowser.open('safari://') keep you in app. This seems like the most robust solution, assuming denying access to wifi is a valid solution. If not, setting a whitelist on the router would be an option, though maybe you need to buy your own classroom router if you are not admin on the school wifi.
-
Thanks for all the help guys. See, I am still trying to figure this out. All students get their own iPad mini with Pythonista on it. They are locked into Pythonista, but I want them coding without using webbrowser. I wish I could just access the internals of Pythonista and simply delete the module. In the meantime, I would settle for some parental restrictions in the module. I don't want the students randomly surfing the web, but sites like this one and stackoverflow might be fine. Any ideas?
-
@jbap , sorry I don't except one. Get your students to solve the problem 😬 Not as stupid as it sounds, they would take pride in creating something that their classmates could not break.
-
if you are able to install your own wireless bridge in your classroom (not sure if all routers let you do this, certainly ones supported by dd-wrt can), then you could log them into the router, then lock them into pythonista. on the router, you would set the firewall to only allow sites on a whitelist.
Another option may be a custom ui module, which you place in site-packages, and which stubs out ui.WebView, or maybe even implements a white list. You could show a "siteminder" page for sites not on the whitelist, so they think it is a router limitation and don't keep digging. Maybe log such attempts, so you can figure out who the aspiring hackers in your class are.
ok, another option... you could install into site-packages a pythonista_startup, which uses objc to swizzle the underlying UIWebView class to be nonfunctional. Then use the chmod trick above to prevent casual editing of that file.
