2
$\begingroup$

I worked out a way to prompt notifications to peopel using my mathematica code that a new version is available. My code is in a private github repository, mathematica can access it using http requests and a token as authentication. Now, Unfortunately github does not allow read-only permissions. So I am afraid to push out the new version with the autoupdate, as it will neeed to contain the token, and if the token is shared anybody could access all my repos. Now, on the internet I found the suggestion to make a new github account and add him to the repo, and then generate the token with this account, in this way at least only a single repo will be at risk. I don-t like this solution much, though. Now I was wondering if there is any way to "hide" the value of the variable to an average mathematica user, still allowing it to be used for commands (basically I just have to insert it in an http request).

Of course I understand that anybody with some computer knowledge can for example sniff the request, but I would already be happy if typing the name of the variable and pressing enter in mathematica would result in it value NOT being displayed, and same regarding the user being unable to get it by opening the file and reading it. The second part is easy, I can use Encode. The first part, however, is a problem. I hoped I could set attributes ReadProtected and Locked. However, these work to hide function definitions, NOT variable values. And also functions can still be evaluated, so I cannot hide my string in a function. Any ideas?

$\endgroup$
13
  • $\begingroup$ [1/2] I think the entire scheme using github-only, is flawed. You probably want to set up your own server, which would accept end-user HTTP requests (with proper authentication), and will communicate with github - in this way your github repo will be insulated from any prying eyes. If you don't expect too much traffic, you might even be able to use Wolfram Cloud for that, deploying a custom APIFunction and setting up proper permissions. In this way, your secret token will only unlock execution of that API function in the cloud, ... $\endgroup$ Commented May 21, 2021 at 0:57
  • $\begingroup$ [2/2] ... and that APIFunction will be responsible for actually checking out the new version of your package from your github repo, encoding it, and returning the response to the WL client, which would decode it and run / install updates. You can set cloud permissions so that the users will have a permission to execute the cloud object / APIFunction (provided that they have a secret token), but not read that CloudObject or modify it - so the code you put there, that will actually communicate with github (using this time a real github token - which of course you don't share), should be safe. $\endgroup$ Commented May 21, 2021 at 1:01
  • $\begingroup$ But even with all that, I would still follow the suggestion to have a separate github private account with just that repo. Github's story for read-only access to repo seems to not be particularly promising, despite the huge demand expressed in that thread. But there seem to be some workarounds and ways out (even with the setup I described above, it is better to not give your cloud API a write permission) $\endgroup$ Commented May 21, 2021 at 1:17
  • $\begingroup$ One last thought: you will obviously have to think also about protecting your code from being read. You may find this Q/A helpful, although you probably are already aware of most of the suggestions discussed there. $\endgroup$ Commented May 21, 2021 at 1:20
  • $\begingroup$ Let me know if these suggestions make sense to you. If they do, then tomorrow I can post a more coherent suggestion / scheme as an answer (it is way too late here now, so calling it a day). That scheme would allow you to completely decouple users from any sensitive information, they will essentially have to register once, and then only send in their HTTP requests their $MachineID (by send I mean that your app will be sending that info on their behalf, of course, fully automatically, without any involvement on their side). $\endgroup$ Commented May 21, 2021 at 2:11

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.