I'm implementing OAuth2 (100% spec compliant) in a project that I've been assigned to.
Let's say I have a file named 'file.txt' on the resource server.
The client wants to download the file. Suppose file downloads are done through another server, dl.example.com , because there may be multiple resource servers, and a common access point for downloads will be a neater approach. (?)
So if the client wants to download a file, and output it to the browser, what should be the preferred process?
If I take the following approach :
1) Client makes request to dl.example.com?access_token=123123&fpath=file.txt
2) dl.example.com makes request to the respective resource server
3) The resource server sends the file to dl.example.com
4) dl.example.com sends the file to the client
5) client outputs the file to the browser for download
there will be additional network I/O overhead.
Is this approach not the right way to go? How to 'big players' like Dropbox do it? I have checked Dropbox's url : dl-web.dropbox.com/*whatever* . Is Dropbox's approach totally different than the above one?
I would not proxy the passing of the file resource via the dl.example.com server.
The access_token is the key here. If the resource servers support OAuth2 themselves and have access to the store for the access_tokens you could respond with a status 303 redirect from the original request to the actual resource address in need:
Original Request: https://dl.example.com?access_token=123123&fpath=file.txt
Response: 303 https://resource.server.com/path/file.txt?access_token=123123
You can flag Curl to follow redirects. If you're developing an Client SDK to wrap access, this could all be invisible.
Related
My platform uses AJAX to make communication with internal structure (API's and others). All AJAX requests are sent to a single file called globalAPI.php (POST Method) and there he communicates with other php files (this was done to hide the internal structure).
Assuming a user discovered how it works and make a request starting from his server. We can conclude that it would generate results without even being logged in my platform.
So how can you protect this file to external access?
I believe I could use a .htaccess file with Allow from 127.0.0.1, but what if the user change his ip to 127.0.0.1, he would have access to this file?
Have another way to protect this file?
You should implement an authentication system in all your API calls if you want to restrict their access.
Basically, you cannot prevent a user from opening the Network tab from the Devtools and watching the requests that your client makes to the server API: an advanced user can see the parameters sent at each request and resend the request with the same or different parameters.
If this file is accessible through AJAX, it is accessible for the client anyway: what you have to do is make sure that the user cannot access more things than the AJAX calls allow him. To do that, secure your API, e.g. requesting a user token for every call: the server would know which user accesses the API and you can handle authorization from that point.
I am converting a working copy of the s3demo-cors.php example code, to ASP.NET. I am trying to understand in which instances the CORS handling is required. For example I see that the PHP code calls the handleCorsRequest() before attempting to delete an object. Why would the server running the PHP code to delete an object on S3 require any CORS headers? Or are those headers used by the client after the script is done running? I perhaps am rusty on when and how exactly the CORS headers are required, but from what I understand they are for the client side JavaScript so it may deal directly with S3 from the browser, not so the server can talk to S3. Additionally, for the delete object feature, what security measures are in place, so that requests coming in to delete objects on S3 are authenticated? Perhaps I am missing where in the code a delete request is first authorized? Is it because the client only knows the key values for object they have uploaded? What is someone else downloads the file, and can see the key value, could they submit a request to delete the object? Thanks.
If your signature server or delete file handler server and uploader instance/page are hosted on the same origin, there is no need to worry about CORS. If your endpoints that handle delete file requests and/or signature requests are on a different origin than the one hosting your upload page, then you will need to deal with CORS.
If you are working in a cross-origin environment, then you must acknowledge the cross-origin requests in your server response appropriately.
As far as authentication/security is concerned, that is your responsibility. Your web app should already handle this.
I am working with a site that builds XML files that are then posted to a RESTful interface. I have built the tool to generate the files and I would like to upload them to the RESTful interface. I am having a slight problem. It would be nice to POST the file using a form, but the "content-type" must be "application/xml" not "multipart/form-data", so that ruled out posting that way. Next, I figured I'd try to cURL the file, but that failed, too.
The RESTful interface requires the user's certificate in order to process data. That's because the interface keeps track of who is uploading based on their cert information. So, I was hoping to get help with one of two options
1) Post the data, and client certificates that are in the browser, to the RESTful interface using cURL
2) Process the data, set the headers properly and then somehow redirect the POST using the client's browser to the page. I know the page will authenticate a user if they go to the RESTful URL. So if I could somehow setup the page data as an "application/xml" and then tell the user's browser "Hey, redirect to this address and send this data"...
Suggestions?
I have a bucket with files in it in AS3. I have access to the PHP API and a server that can send requests to Amazon on command.
What I want to do is grant access to a file in my bucket using an HTTP GET/POST request. From what I understand using this function:
get_object_url ( $bucket, $filename, $preauth, $opt )
I can make the file publicly accessible for the $preauth amount of time at a given URL. I don't want to do that, I want the file to be privately available at a URL with required POST or GET credentials (deciding who can access the file would be based on a database containing application 'users' and their permissions). I understand the security implications of passing any kind of credentials over GET or POST on a non-HTTPS connection.
Is this possible? I could just download the file from AS3 to my server for the extent of the transaction then do all the controls on my own box, but that's an expensive solution (two file downloads instead of one, when my server shouldn't have had to do a download at all) to a seemingly easy problem.
The short answer is no.
You could look at Amazons IAM for some more ways to secure the content especially in conjunction with Cloudfront but essentially there is no way to provide access to content by passing along a username and password.
Of course, if you are already authenticating users on your site, then you can only supply the signed url to those users. The url only has to be valid at the time the user initiates the download and not for the entire duration of the download.
Also, if you intend to use your server as a proxy between S3 and the user you'll be removing a lot of the benefits of using S3 in the first place. But you could use EC2 as the server to remove the extra cost you mentioned - transfers between S3 and EC2 are free.
I'm building a web-radio like service, in which the user authenticates to the services, gets a cookie and a Flash-based app plays mp3s from the server. The server only delivers if the client is allowed for that particular mp3.
If a user opens a HTTP logger (like FireBug), he can see the files being downloaded by flash. If he opens the mp3 URL directly via the address bar, he can easily download the MP3, although the URLs are not guessable by the user.
I'm looking for a safe system to prevent the user from downloading the MP3 directly to his system. I have examined last.fm, as they use a similar setup, and somehow they prevent it.
In the end, you're not going to be able to stop someone who's determined. However, you can at least make it difficult.
There are several options involving referrer checks, authentication, and fun stuff like that. But probably the most successful anti-downloading check I've seen was one that works like this:
The user indicates that he wants to stream a file; the app makes an authenticated, encrypted request indicating his desired action. The result is a one-use-only and time-limited URL that is recognized by whatever application or CDN is hosting the file. After the URL is used once (i.e. by the flash app) it then expires and can never be used again. If the streaming does not start within a given amount of time (several seconds), the URL likewise expires. Obviously the URL given does not directly correspond to the file name, but is instead authenticated, decoded, and translated server-side.
It's still not impossible to work around, but it's fairly difficult.
You might use RTMP instead of HTTP to deliver audio data. RTMP is meant to be used for streaming audio, video and misc data. It streams just data rather than a file. It's not 100% safe, because if something gets to client (browser, flash player, whatever), user can save it, but it's still better than giving a file via HTTP.
You will need a server that supports RTMP though, e.g., Flash Media Server (FMS), Wowza or Red5.