Way to make salted api call within a package?

question

#1

Two use cases:


Let’s say you wanted to record troubleshooting information from inside your package. However, you don’t want endusers (at the applications* level) to have access to your api for sending the diagnostic info.

Is there a way to send an api request that’s salted in a way that the user can’t feasibly break it?

*using the nomenclature of: Distinguishing projects from packages


Let’s say you have some jupyter-based web form that boils down someone’s preferences to a single api request that stores the associated information in some company-owned SQL database.

Again, “Is there a way to send an api request that’s salted in a way that the user can’t feasibly break it?”


The setups are completely hypothetical. They are assumed to be unhackable and take some finite amount of time to complete by a user.

The main question is:

  • Is there a way to send an api request that’s doesn’t allow a user to modify it (and still have it work)?

#2

I’m not sure if it agrees or disagrees with your usage, but I’ve posted an update on the nomenclature that we’ve settled on in Pkg3:


#3

I think you need to put constraints on your “unhackable” assumption to get meaningful answers here. Aren’t you asking for protections against “hacking”?

Unless you fully control the system they’re working on, it is possible for the user to break/mimic/forge/duplicate any API requests you make on their behalf. You can only obfuscate things to make it harder. The question then is where the bounds are on what is hard enough to be considered “hacking.”

The typical solution to this problem (e.g., in online games) is to make the clients dumb. It’s the server that keeps track of how much money your character has, because otherwise I could just tell the server myself that I have a million gold pieces.


#4

You have a million gold pieces‽


relevant post:


#5

Would it be more like #1 storing a fixed hash and only allowing the TS code to run with the matching password passed as an arg, or #2 trying to stash some hidden functions in a module in the package, which would probably always be accessible but obfuscated / not advertised, or more String (/Api?) related