I am creating a Rails app that will have User and File models. A user "has many" files. The catch is that the files are never created by the user explicitly through the web application. I am building desktop applications to monitor the filesystem (think Dropbox) and create/update File records.
Is the correct way to do this to have the desktop applications make the appropriate POST requests to my Rails application and just not supply a view for creating File records in the web app.
Also, would it be sufficiently secure to require a user-specific security token to be sent in the POST request made by the desktop applications to authenticate a user's file record?
It sounds like you're on the right track. Your Rails app is essentially exposing an API that takes an uploaded file and created the associated model on the user's behalf to track the file metadata. You could still expose a view in your webapp to edit file metadata and delete files, perhaps.
Security is a whole topic of its own. At a minimum, you'll probably want all communication to happen over SSL, and expire the token on a set timeout. Devise can do this for you with their TokenAuthenticatable implementation. You'll probably also want to limit file upload size and throttle requests.
Related
I'm new to PouchDB but want to use it in my recent project. The main concern is of course security. I'd like to build a multiuser, desktop app (Electron-based) that allow users to modify documents in the same pouch/couch DB.
Because of some workflows some parts of the same documents should only be change by particular users. As I understand the only way to do it in Javascript/Pouchdb app is to add permission logic to client side JS, and that dosen't sound secure at all. Am I right? What is the real thread here? How easy it is to bypass client-side js permissions and change pouchdb document in an unauthorize way?
thanks for clearing that up
Once you give open code to end-user side (which is JS case) you should be ready to accept possibility of malicious code change client-side, that's obvious.
Since CouchDB manage write permissions on per-DB basis - malicios user will write to all docs in that DB if he has write permission there.
Consider per-user DBs and then combine your multipart final docs server side only or consider other DB.
I have a Ruby on Rails-based website from which I want to create a stand-alone application (desktop app) so that users have an interface from their own computer without opening the browser and so that access is restricted to the people that have the app.
I am looking at the security of this and not sure how exactly to best go about this.
In a typical ROR site you have a database.yml file with your database information in it.
If I use RubyScript2Exe I think it would be too easy for someone to access this information. Maybe I am wrong.
My question is should I build this app as an API only thru my main site or should I build it to directly interface with the database.
One other option is to create its own database on each desktop computer to save their posts and an interface with the main database thru an api call.
My app will need to:
Create New Records in Database
Search Database
Delete records created by user
Main site uses Devise for log-in authenication
I'm developing an application which lets users upload pictures. I'd like to use Google cloud services to store these pictures. I am creating a unique GUID for each image in database and would like to store the images in the cloud with that name. It makes sense for me to make an ajax request for a GUID and then upload the image from the same page directly to google cloud services.
https://github.com/GoogleCloudPlatform/storage-getting-started-javascript/blob/master/index.html
Like shown in this example.
My first question is, should I be sending this to my back-end(C# code) and uploading it from there? Or is this the correct approach?
And my second question if this is the correct approach is, wouldn't exposing my details like that in javascript allow other people to upload from outside my application as well?
An API key, by itself, identifies a call as being associated with a certain project for purposes of billing. It's only necessary for anonymous calls. An API key does not grant any sort of authorizations. If there's an object in a bucket in your project that only your project members can see, the API key won't give anyone permission to read it.
That said, it's not a great idea to share your API key if you can help it, and if you need to share it, you should lock it down as much as possible. API keys can be limited to use with only certain IP addresses, only with certain web referrers (for instance, it will only work with JavaScript clients on www.yoursite.com), or only when run from a particular iPhone or Android app. These precautions aren't cryptographically fool-proof (there's no reason a hacker couldn't spoof a referer header), but they do make them pretty much useless for someone else who just wants to paste an API key somewhere to enable a web app and doesn't want to pay for it themselves.
The problem with using the javascript client's approach for your application is that individual users would either end up uploading objects completely anonymously or with their own Google accounts. Neither is super great, since the anonymous option would basically require you to create a bucket with anonymous writes enabled, and you don't want to do that.
There is a great approach to letting users upload pictures, though: signed URLs. Signed URLs allow your server to securely sign, in advance, a request to upload an object with your credentials. This is your best option for letting anonymous end users securely upload objects to your buckets.
Documentation on signed URLs: https://cloud.google.com/storage/docs/accesscontrol#Signed-URLs
I am trying to restrict access to files in a directory and it's sub directories based user rights. My user rights are stored in an MS SQL database in a custom format, however it is easy to query the list of users with rights to this directory.
I need to know how to apply this to a web config on the server to authenticate against a query of a database table to determine if the username is authenticated and allowed to view the file. Of course if they are not they should be blocked / given a 404.
I am using IIS and ASP.Net MVC3 with a form based security as opposed to the built in roles and responsibilities that was custom made for us and that works great. There are over 10k users tied to this non-Active Directory authentication so I am not planning to change my authentication type so please don't go there.
It is not my decision on the choice of platform, or I would have gone with a LAMP server and been done with this.
Edit 11-13-2012 # 8:57a:
In the web config can you put the result of an SQL query?
I have answered something similarly in the past (uploading and accessing files), but the principles still apply in providing access to file system level files.
in asp.net-mvc, is there a good library or pattern to follow when saving users content (images, files, etc)
I want to to decouple some parts in my rather large app and delegate them to an external node app, mainly for uploads but authentication remains a problem.
On the Rails side I'm using Devise, clients and forms will point to this new subdomain where the node app resides.
The node app is using express and I can connect to the shared database through the mysql module.
The idea is to use heroku for the main app, and delegate uploads to a node app running on a EC2 instance. In order to access the app I want to pass authentication informations, given that this endpoint will used by both API clients and web forms.
Devise has support for authentication tokens passed via URL, but I'm wondering what are your solutions.
Well if your subdomains are just 1-dot apart like www.myapp.example and uploads.myapp.example, you can share both the session cookie and the session info in the DB. I would just code the node app to validate the session cookie on every request the same way devise does and you're done. Is the upload subdomain user facing, as in does it render HTML to the browser or have to display a login form? If so, than the shared session table in the DB is probably not the best idea, but if the node.js is just for uploads and can redirect to www.myapp.example when the session is not valid, all should be well. Just make sure you set the domain field of the cookie to .myapp.example.