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
Related
I have an existing web application that's developed with Ruby on Rails and PostgreSQL. I need to create a mobile application (and possibly a separate web application) using the data from that web application, so I'm looking to create an API server. Is it possible to do this without altering the source code from the original Rails/Postgres web application?
Any ideas on the best way to do this? Or can someone point me in the right direction on what to research?
To connect a new application hosted on Heroku to a PostgreSQL database hosted on Heroku just push your new application to Heroku as normal.
Then, under Settings on your new application dashboard, go into Config Variables and add a new config for DATABASE_URL. Put the value of the url for your existing database.
Your new application will need to be under the same account as your existing application. Heroku doesn't allow you to connect across accounts.
You probably want to take a look at this question for additional details.
Sounds like essentially you want to have two applications connecting to the same database offering the same methods, but respond in different formats (html vs, for example, json). One way of doing that relatively easily might be pushing another api only Rails app to heroku that connects to the same Postgres database (which was mentioned in the comments), but you would have to figure out how to handle authentication differently for your API end points. This depends on whether you are exposing these end points to the public or to something like a mobile front-end. You may want to switch to token-based authentication if you were formerly using sessions on the web-app. Once you implement secure authenticatoin for your api routes, all you have to do is make sure your methods, instead of rendering erb or haml templates, are returning raw data consumable by your intended client.
I have been working on an Angular/Ionic application and am using the OAuth.io plugin to handle a facebook login to gain a user's information. From that I derive a simple database name based on the user's firstname and their Facebook ID number.
What I am wanting to do would be to sync this local pouchDB instance to an online CouchDB instance (currently using http://iriscouch.com) for replication to a desktop app, or something similar. The piece I am missing is how to handle user authentication/authorization to be able to only read and write to their own database and no one else's as all of the code currently lives on the client side with no app server to handle any login aside from the OAuth.io plugin.
Is this possible to handle without adding an app server layer, and without manual intervention to create a user on the CouchDB instance?
Currently you can only do per-user read-write permissions in CouchDB by having an additional process on the server side (details), which would be troublesome for you since you're using IrisCouch, so you'd need a separate server somewhere to host this process.
A few alternative options are available to you right now:
Couchbase, which has per-user databases
Janus, which works using Mozilla Persona rather than Facebook ID, and isn't ready yet, but should be unveiled shortly
I have been working on iOS application for sometime, and I am using Core Data to manage the SQLite database for the application. The users of the application can update the data associated with their account using the application, but I would like to create a simple web form where users could update certain information asosciated with their account. Basically I would like a user to be able to access a web adress from their personal smartphone or computer, login, then update information asociated with the account stored on the iOS device. What are the possible solutions I could use to accomplish this?
Breaking down your question:
Currently you have an iOS app which uses a local SQLite DB to store data
You want to let users update information in this DB remotely (i.e, via a web site)
Unfortunately to do this you're going to need to make some significant changes to how your app works. This is because it's impractical - if not nearly impossible - to do this kind of thing and keep the database local to your device.
The standard way of achieving this would be to store your database remotely on a web server, and then have both your app and your web form interact with this server to retrieve and update data.
There are lots of different ways to do this. Fundamentally, you'll need a server running a database, and a web service to access it. You could implement this yourself, using something like MySQL or PostgreSQL, along with a language of your choosing (Ruby, PHP, Node, etc). Another option is to use one of several 'backend as a service' providers. These are companies that provide 'out of the box' backend functionality for mobile apps. Two popular providers are Parse (owned by Facebook) and Stackmob.
Whether you choose to do it yourself or use a backend provider will depend on how confident you are. It's not an especially hard or tricky thing to put together on your own, but there are several common pitfalls you're likely to encounter.
I currently have a ASP.NET MVC 2 web application and would like to enhance the architecture to support a SAAS model. I plan on eventually building a number of web applications so would like to design the system accordingly.
The goal would be that when a client would hit the following url clientxyz.domain.com they would see an image of all their subscribed applications. This would essentially be a web page with a bunch of application icons. Once a client would click on a icon it would navigate to that actual web app at the following example url clientxyz.domain.com/application_name.
We currently use GoDaddy to host our domain and plan on using a Cloud based iLand server to host our application. We only plan on a few new clients a year due to the nature of our software.
I have a number of questions:
Is it possible to programmatically create subdomains on the fly using a .Net api. I'm pretty sure GoDaddy does not let you do it. So is there another provider that would let me create subdomains via C#. This may be the wrong approach and may not even need to physically create client subdomains. Instead I may be able to accomplish this using url rewriting in IIS/MVC?? If I use rewriting, it would have to satisfy the url requirements mentioned above. Any suggestions/links/examples?
Should I create a separate IIS website for each tenant/client? Or should I use URL rewriting and simply have a single website / application pool? Looks like you can programmatically spin up IIS websites (example: http://www.eggheadcafe.com/tutorials/csharp/d4bba585-b517-4834-8476-ff05b085d86e/iis--create-app-pools-virtual-directories-and-web-sites-c-net.aspx)
Since we are using a Virtual Server on iLand do I simply have to point GoDaddy to the nameserver at iLand.
I would like to automate the entire new client process if possible. To accomplish this, I would have to created the database (probably going to have single db per tenant), populate the global client/tenant table, create admin user account and subscription details in newly created database and create subdomain depending on approach. Am I missing anything?
thanks in advance.
I'm planning to build a group of several Rails applications on Heroku, and I want to share accounts, user data, and maybe some other information between these applications and the "main" Rails app. What would be the easiest and most effective way of doing this?
I've heard that one way of doing this is to make all the applications share the same database, but I'm not sure if that's really the best solution in my case since I only need to share some information between these apps. Another thing I've considered is using the CAS protocol, but that only seems to handle authentication (I can't use it to get user's names and email addresses). Suggestions?
Here's how I'm considering doing this.
Create a master app with user authentication.
Have each sub-app do omni auth with the master app.
Then the master app will house all the user data, and the sub-app will get the authentication info necessary plus the user data. I haven't figured out how to make sure that new user data will be saved in the master app, but it seems like you would just send the user to the master app, then have them returned once they've entered the data.
Any suggesting from you Rails experts out there before I sink a week into doing it this way.