I'm a website designer who's fairly new to rails. I'm building a custom CMS for the websites I design.
The idea is that clients will be able to login to their cms panel (on their individual domain and hosting) and can submit a support ticket which will be forwarded to my admin panel on my domain and hosting.
Is anyone aware of a learning resource for this type of function?
Any advice would be great, thanks.
Rails is primarily built to handle web requests, so that's the most straightforward way to interact between Rails apps. Just create a post request containing the ticket info, targeted at your admin panel app, which has the typical Rails setup to handle it.
Rails uses helpers called routes to efficiently handle form submissions. Instead of the expected route any form_for #mymodel can specify a url to send the form to, ostensibly to an offsite url as you desire.
Related
I'm working on building a closed community forum for members of an existing site I also built. I'd like to allow members to sign in to the new forum using their existing accounts on the main application. The forum will be on a different domain from the main site.
This will be my first time using OAuth. Most information on the web about it seems to skew heavily toward allowing users to sign in with Twitter/Facebook/etc accounts, and there's very little information that seems pertinent to what I'm working on.
I'd like to create an OAuth provider in the original web app and a OAuth client in the new app I'm building. No other providers will be used, and no other client sites will be authenticating off this main site. Additionally, I need to avoid any sort of "authorize this web site" intermediary step for my users.
The main site is Rails 4 with Devise, and the new site is Rails 5. I'd like to stick with Devise on the new site as well, which I understand can function as an OAuth client. Doorkeeper seems like it could be overkill for my exceedingly simple needs, but most other information I've found is years out of date, so I don't want to invest time pursuing an implementation that won't work or is not the current best approach.
What is currently the best way to handle this kind of single-client, single-provider setup?
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 an ASP.NET MVC Application and the routing urls looks as follows:
foobar.com/users/8
foobar.com/users/90
foobar.com/exercise/details/5
foobar.com/exercise/details/400
So with this URL route, a user can manipulate the URL directly and change the ID's which are integers. What is the best practice of securing this so that users can't easily manipulate the URL ID's? How do enterprise applications handle this?
For a well designed system, users manipulating URLs should not be an issue. Even if you send the data in an HTTP Post body, users can still manipulate it using an intercepting proxy such as Burp.
Relying on secrecy of IDs (for example, choosing IDs randomly) is also not a solution. In pentester terminology, you will be vulnerable to direct object reference. The classical terminology for this flaw is violation of the complete mediation principle.
Instead of worrying about what users may do with URLs and content sent to your server, you should be securing the server from malicious inputs. The issue here is authorisation. I recommend you have a good, thorough read of Securing your ASP.NET MVC 4 App and the new AllowAnonymous Attribute and NerdDinner Step 9: Authentication and Authorization.
A lot of applications are designed to be URL hackable in that the user can change values. A lot of users like to manipulate the url to change page number, record, etc.
There is nothing wrong with this As long as you make sure its all secure. For instance your Details action should check the user can access record 5 before showing it.
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 am reading the Service Oriented Design with Ruby book by Paul Dix and many posts here but am left with many questions surrounding authenticating users and the application.
I want to have api.site.com as a RESTful Rails app serving up JSON. Secure.site.com will be a web app (maybe Rails or maybe PHP) that will consume the service. Also a mobile app such as iPad will also consume it.
So is the first step to build in a level of auth so that only my web app and mobile app can consume the service? Then once the calling app has been authenticated, both these apps will have users who want to CRUD their data so then authenticate them as well?
I've read about Http basic, digest, tokens, oauth and many plugins but am having a difficult time narrowing down the most flexible and reusable way. For now this is simply learning so I would like to stay away from plugins so I can learn the code better.
Can my web app use normal sessions like I'm familiar with and then the mobile use their equivalent to sessions. At that point I still have no authenticated the calling app though. Http basic seemed like I could use it from both, but I didn't see a way for my web app to use a normal login form and logging out seemed like an issue.
I would suggest two solutions for you.
Use a Gem like devise for login system and inherit the devise registration and sessions controller to make it respond to JSON requests.
Create your own simple authentication and use respond to HTML and respond to JSON for separating web and mobile login
Iam not totally sure whether a mobile device maintains a session (please look around) but u can always use a token authentication system if it doesnt.