A way to run a HTTP query via the domain server, with a header indicating user?


#1

Scripts that run client-side that can communicate with the outside world (via HTTP requests) will always be limited - there’s no way of the destination HTTP server to know exactly where the communication came from.

This limits the ability to offer personalised services.

What if:

A function exists in the JScript VM for the interface, which when called will communicate with the Domain Stack to say “%User wishes to perform HTTP query to %Destination.”, and then the Domain stack carrying out this function, embedding the User’s ID (Logging in username as a UID), and the current domain of the user in the header so that the PHP can do whatever it needs to do knowing that it’s defintiely the user.

This also provides a level of security for the user’s IP address as queries sent from the Domain Stack will not contain the user’s IP address – this also adds another possibility of authentication because the PHP server can check to ensure the IP address is from a certain IP address which is known to be the domain server.

Then after performing the query, the domain server simply passes the response information back to the user.

Thoughts?

Idea for a Security Solution

  1. Client-side script executes a HTTP query to a php server using the system proposed above.
  2. Domain server checks to see if user exists within the domain before sending.
  3. Domain server then sends a request to the destination server with the User and Domain embedded in the header.
  4. PHP back-end receives the request and then uses an API (Another proposal) to also verify the user exists within that domain, and that the domain IP address matches the source of the request.
  5. PHP back-end can now be pretty sure that the communication is secure, rather than someone doing a manual HTTP request client-side, manually creating the header to bypass security measures.

Update: Added to worklist: https://worklist.net/20717


#2

I think domain servers already authenticate using oauth (I may be wrong, but you can set it to only allow certain users to enter or edit). It is just a matter of getting that info into the script if that’s the case.

I agree that it’s probably not good if domain servers can get your ip address. This could be used to hack users machines.


#3

It would be a simple but powerful way to communicate with the outside world for things like custom-built messaging systems, or in-game credits, etc etc… No implementing OAuth2, just a simple passage way for a message to travel from local script to domain server to outside world, but for the outside world to be able to be sure the message is from the user by requesting a nod from a central server of “Is %User in %Domain, and is %Domain at %IP”…


#4

The userlist shows what domain they are in. (If they have their location set to public.)

https://metaverse.highfidelity.com/api/v1/users?status=online


#5

Do we have a sure fire way of determining the IP of the domain though?

And the query would have to come from the domain server itself so we can verify that the point of origin was the domain server.

If we have those two elements, then the final element would be implementing the query function that gets transmitted from the domain server, not the user client.

Then we’d have a way to authenticate a user and provide user-specific results.


#6

Added to worklist: https://worklist.net/20717


#7

That is not a scalable approach to this problem. The entirety of HF is a scalable distributed architecture. There could be cases where a proxy server is interposed to do load levelling. Your approach would require successive queries to reform the chain of trust on every transaction. What you need is a token based system (there are several such standards) that abstract the physical server or committed IP addresses.


#8

That is not a scalable approach to this problem. The entirety of HF is a scalable distributed architecture. There could be cases where a proxy server is interposed to do load levelling. Your approach would require successive queries to reform the chain of trust on every transaction. What you need is a token based system (there are several such standards) that abstract the physical server or committed IP addresses.

Absolutely, however such an implementation I imagine is quite some time away. For the time being, a solution that is one step above the transparency that currently exists would be desirable at least.


#9

They have already said they will implement oauth for this. It’s already halfway in (or maybe fully implemented for all I know).

Generate identity tokens here:

And you can use
https://metaverse.highfidelity.com/oauth/token/info?access_token=insert token here

to look up the info.

I believe they are using doorkeeper


#10

I get that, but at the moment there’s no way to integrate that in to what I’m looking to achieve.

Say you had a button inside your domain that when you pressed it, it would send a HTTP request to your website… On the website is a php script who will receive the HTTP request and perform actions depending on who you are.

What I’m looking to achieve is a way for the php script to be able to know who pressed the button, and eliminate the possibility of someone else making a script and tricking the PHP server in to thinking it’s somebody else by changing a string from say ‘GlobalServices.username’ to ‘micah’… If that makes sense?


#11

Yes I gathered that from your first post.

Well… domain stacks already use oauth, and the domain stack code is open sourced… Why not use it for authentication outside of the domain?

What you are talking about is what oauth was specifically designed to do. It’s the same API authentication used by sites like twitter, github, google+ and facebook. Good luck trying to figure it out though… I have been looking at how HiFi uses it for the last week or so, and still not there because lack of documentation and obfuscated code.