cancannible role-based access control gets an update for Rails 4
Can You Keep a Secret? / 宇多田ヒカル
cancannible is a gem that has been kicking around in a few large-scale production deployments for years. It still gets loving attention - most recently an official update for Rails 4 (thanks to the push from @zwippie).
And now also some demo sites - one for Rails 3.2.x and another for Rails 4.3.x so that anyone can see it in action.
So what exactly does cancannible do? In a nutshell, it is a gem that extends CanCan with a range of capabilities:
- permissions inheritance (so that, for example, a User can inherit permissions from Roles and/or Groups)
- general-purpose access refinements (to automatically enforce multi-tenant or other security restrictions)
- automatically stores and loads permissions from a database
- optional caching of abilities (so that they don't need to be recalculated on each web request)
- export CanCan methods to the model layer (so that permissions can be applied in model methods, and easily set in a test case)
read more and comment..
555 Timer simulator with HTML5 Canvas
The 555 timer chip has been around since the '70s, so does the world really need another website for calculating the circuit values?
No! But I made one anyway. It's really an excuse to play around with HTML5 canvas and demonstrate a grunt & coffeescript toolchain.
See this running live at visual555.tardate.com, where you can find more info and links to projects and source code on GitHub.
(blogarhythm ~ Time's Up / Living Colour)
read more and comment..
Learning Devise for Rails
(blogarhythm ~ Points of Authority / Linkin Park)
I recently got my hands on a review copy of Learning Devise for Rails from Packt and was quite interested to see if it was worth a recommendation (tldr: yes).
A book like this has to be current. Happily this edition covers Rails 4 and Devise 3, and code examples worked fine for me with the latest point releases.
The book is structured as a primer and tutorial, perfect for those who are new to devise, and requires only basic familiarity with Rails. Tutorials are best when they go beyond the standard trivial examples, and the book does well on this score. It covers a range of topics that will quickly become relevant when actually trying to use devise in real life. Beyond the basic steps needed to add devise in a Rails project, it demonstrates:
- customizing devise views
- using external authentication providers with Omniauth
- using NoSQL storage (MongoDB) instead of ActiveRecord (SQLite)
- integrating access control with CanCan
- how to test with Test::Unit and RSpec
I particularly appreciate the fact that the chapter on testing is even there in the first place! These days, "how do I test it?" should really be one of the first questions we ask when learning something new.
The topics are clearly demarcated so after the first run-through the book can also be used quite well as a cookbook. It does however suffer from a few cryptic back-references in the narrative, so to dive in cookbook-style you may find yourself having to flip back to previous sections to connect the dots. A little extra effort on the editing front could have improved this (along with some of the phraseology, which is a bit stilted in parts).
Authentication has always been a critical part of Rails development, but since Rails 3 in particular it is fair to say that devise has emerged as the mature, conventional solution (for now!). So I can see this book being the ideal resource for developers just starting to get serious about building Rails applications.
Learning Devise for Rails would be a good choice if you are looking for that shot of knowledge to fast-track the most common authentication requirements, but also want to learn devise in a little more depth than a copy/paste from the README and wiki will get you! It will give enough foundation for moving to more advanced topics not covered in the book (such as developing custom strategies, understanding devise and warden internals).
read more and comment..
Punching firewalls with Mandrill webhooks
(blogarhythm ~ Fire Cracker - Ellegarden)
Mandrill is the transactional email service by the same folks who do MailChimp. I've written about it before, in particular how to use the mandrill-rails gem to simplify inbound webhook processing.
Mandrill webhooks are a neat, easy way for your application to respond to various events, from recording when users open email, to handling inbound mail delivery.
That all works fine if your web application lives on the public internet i.e. Mandrill can reach it to post the webhook. But that's not always possible: your development/test/staging environments for example; or perhaps production servers that IT have told you must be "locked down to the max".
Mandrill currently doesn't offer an official IP whitelist, so it's not possible to use firewall rules to just let Mandrill servers in. Mandrill does provide webhook authentication (supported by the mandrill-rails gem), but that solves a different problem: anyone can reach your server, but you can distinguish the legitimate webhook requests.
I thought I'd share a couple of techniques I've used to get Mandrill happily posting webhooks to my dev machine and servers behind firewalls.
Using HAProxy to reverse-proxy Mandrill Webhooks
If you have at least one internet-visible address, HAProxy is excellent for setting up a reverse-proxy to forward inbound Mandrill Webhooks to the correct machine inside the firewall. I'm currently using this for some staging servers so we can run real inbound mail scenarios.Here's a simple scenario:
- gateway.mydomain.net - your publicly-visible server, with HAProxy installed and running OK
- internal/192.168.0.1 - a machine on an internal network that you want to receive webooks posted to 192.168.0.1:8080/inbox
Say the gateway machine already hosts http://gateway.mydomain.net, but we want to be able to tell Mandrill to post it's webhooks to http://gateway.mydomain.net/inbox_internal, and these (and only these) requests will be forwarded to http://192.168.0.1:8080/inbox.
Here are the important parts of the /etc/haproxy/haproxy.cfg used on the gateway machine:
globalObviously the path mapping is optional (but neat to demonstrate), and I've left out all the normal HAProxy options like balancing, checks and SSL option forwarding that you might require in practice, but are not relevant to the issue at hand.
#...
defaults
mode http # enable http mode which gives of layer 7 filtering
#...
# this is HAProxy listening on http://gateway.mydomain.net
frontend app *:80
default_backend webapp # set the default server for all requests
# next we define a rule that will send requests to the internal_mandrill backend instead if the path starts with /inbox_internal
acl req_mandrill_inbox_path path_beg /inbox_internal
use_backend internal_mandrill if req_mandrill_inbox_path
# define a group of backend servers for the main web app
backend webapp
server app1 127.0.0.1:8001
# this is where we will send the Mandrill webhooks
backend internal_mandrill
reqirep ^([^\ ]*)\ /inbox_internal(.*) \1\ /inbox\2
server int1 192.168.0.1:8080 # add a server to this backend
Job done! Our internal server remains hidden behind the firewall, but Mandrill can get through to it by posting webhooks to http://gateway.mydomain.net/inbox_internal.
Tunneling to dev machines with ngrok
For development, we usually don't want anything so permanent. There are quite a few services for tunneling to localhost, mainly with developers in mind. Lately I've been using ngrok which is living up to it's name - it rocks! Trival to setup and works like a dream. Say I'm developing a Rails app:# run app locally (port 3000)
rails s
# run ngrok tunnel to port 3000
ngrok 3000
Once started, ngrok will give you http and https addresses that will tunnel to port 3000 on your machine. You can use these addresses in the Mandrill webhook and inbound domains configuration, and they'll work as long as you keep your app and ngrok running.
read more and comment..