Software Engineer working since 2008 with Ruby / Ruby on Rails, love a bit of Elixir / Phoenix.
I also poke through other people's code and make PRs for OpenSource Ruby projects that sometimes make it. Currently working at Juniper Education making code for UK schools.
Just read a nice little tip in the “Developing Facebook Platform Applications with Rails”. If you’re working off a laptop in an office or at home and you want your app to be viewable on the public internet you don’t have to develop on a remote server. You can however use ssh to forward requests from a remote server (if you have one) over an ssh tunnel to your local machine.
Once minor addition to your /etc/ssh/sshdconfig
GatewayPorts clientspecified
and reload the config. Be very careful here, there’s nothing worse than changing your config and accidentally locking yourself out of your remote machine.
Accessing http://yourserver.com:9000 will now serve the application over the tunnel. Obivously your provider will need to allow the port you are trying to access available. Some ports are locked down by firewalls and so a little extra running around may be required.
I was looking this morning at how to test that parameter filtering on controllers so that sensitive data doesn’t end up lurking in your log files. ie. credit card numbers, passwords. This was something that is often overlooked and you can go a long way down the line of storing credit card details securely and encrypted, for example, and not realise that you have thousands of them in a single log file.
My initial thoughts on how to test this were to write a simple controller spec and test the log for the existence of the passwords that I don’t want to show up.
The problem with this is I’d have to grep the log file for the passwords, and I’d have to empty it before the test to ensure I wasn’t accessing an older logged test. Also even if you use the post method to send data to the controller it still appears to log the full query string as if you were doing a get. Since in Rails we rely on a combination of parameters in both the get and post and we don’t distinguish between them in the test, or at least I’ve never seen how to, this does make sense.
Processing FooController#index (for 0.0.0.0 at 2009-05-18 08:48:20) [POST]
Parameters: {"password_confirmation"=>"[FILTERED]", "action"=>"index", "controller"=>"foo", "password"=>"[FILTERED]"}
Completed in 8ms (View: 1, DB: 30) | 200 OK [http://test.host/foo?password=kj123ert&password_confirmation=kj123ert]
So another solution presents itself. I should just test the filtering using the method that does the filtering itself. Fortunately it wasn’t that difficult to track down.
Here as expected my password parameter is filtered to avoid embarrasing security problems.
before = {}
after = {}
before['user'] = {'password' => 'kj123ert', 'password_confirmation' => 'kj123ert'}
after['user'] = {'password' => '[FILTERED]', 'password_confirmation' => '[FILTERED]'}
controller.__send__(:filter_parameters, before).should == after
I’d say that browser incompatibility is a pretty big bane of any developers life and I was glad to see recently that IE8 is now being pushed as a High Priority / Important update. My current project is plagued by users that continue to use IE5/IE6 even though IE5 has come end of life and IE6 will not get any further updates from December 2009.
The statistics if taken on face value suggest the IE6 is going to disappear in the near future and as developers we can hope to be rid of it soon. However, this is not the whole story. Many of our users are using systems in Primary and Secondary schools who have little or no Systems Administration and rely on a teacher who may have owned a computer once and made the mistake of mentioning it and so have the enviable task of managing the school network with next to no experience.
For these users, we hope that the Automatic Updates get run and everything is upgraded. But the reality may be that they continue to use Windows 95 and IE5 for years to come and that this for this small percentage of IE6 users turns out to be 50% of our client base.
Myspace are asking developers for feedback on their Developers platform. So if you’ve run into any bother, have any gripes, offer suggestions or want to praise them. This is the place to do it.
Currently wrestling with verifying requests from Myspace. Found this same code on the Myspace developer forum and posted from Jarkko Laine on a the following Google group this hopefully this should be on the right tracks. It wasn’t working immediately.
I assumed that OAuth was purely for the remote server-side working as a client for accessing remote protected resources. It appears that you get oauth parameters passed through with the initial request to your iFrame when viewing a Canvas. This can be verified by the application server to ensure the incoming request is from Myspace and the ‘opensocial_viewer_id’ in fact relates to the Myspace user who is looking at your application.
CONSUMER_KEY = "xxxxxxxx"
CONSUMER_SECRET = "yyyyyyyy"
require 'oauth'
require 'oauth/consumer'
require 'oauth/request_proxy/action_controller_request'
def oauth_required
consumer = OAuth::Consumer.new(CONSUMER_KEY, CONSUMER_SECRET)
begin
signature=OAuth::Signature.build(request) do
# return the token secret and the consumer secret
[nil, consumer.secret]
end
pass = signature.verify
logger.info "Signature verification returned: #{pass}"
rescue OAuth::Signature::UnknownSignatureMethod => e
logger.error "ERROR"+ e.to_s
end
render :text => "OAuth access denied", :status => :unauthorized unless pass
end
signature.verify always seemed to always return false, after initially following these two threads thinking that the problem was because the signature was actually escaped incorrectly. This in fact is a problem that is resolved in 0Auth 0.3.2.
I realised it was my error entirely. I made an assumption that the ApplicationPlatform was purely for opensocial and MyspaceID was purely for OAuth/REST. So I was using entirely the wrong oauth key/secret. Having only two applications setup I didn’t notice the ApplicationPlatform also had OAuth keys and in fact you can use OAuth with it too…in fact you need to in order to verify the incoming requests.
I’ve simplified the code from above as not all of it is needed.
def oauth_required
key = 'xxxxxxxx'
secret = 'yyyyyyyy'
consumer = OAuth::Consumer.new(key, secret)
verified = OAuth::Signature.verify(request) do
[nil, consumer.secret]
end
unless verified
render :text => "OAuth access denied", :status => :unauthorized
end
end
Really strange problem today, it appears that 1.1.3 has an issue. Upgrading to 1.1.4 fixed the problem.
>> Artist.all.to_json
ArgumentError: wrong number of arguments (2 for 1)
from /usr/lib/ruby/gems/1.8/gems/json-1.1.3/lib/json/pure/generator.rb:300:in `to_json'
from /usr/lib/ruby/gems/1.8/gems/json-1.1.3/lib/json/pure/generator.rb:300:in `json_transform'
from /usr/lib/ruby/gems/1.8/gems/json-1.1.3/lib/json/pure/generator.rb:299:in `map'
from /usr/lib/ruby/gems/1.8/gems/json-1.1.3/lib/json/pure/generator.rb:299:in `json_transform'
from /usr/lib/ruby/gems/1.8/gems/json-1.1.3/lib/json/pure/generator.rb:272:in `to_json'
from (irb):7
Trying to add a new plugin which will be a submodule of a the main project I am working on.
cd ~/project
./script/generate plugin myplugin
mv vendor/plugins/myplugin ~/
cd ~/myplugin
git init; git add .; git commit -m "Plugin skeleton";
cd ~/project
# add the submodule to the project
git submodule add ~/myplugin vendor/plugins/myplugin
# initialise and pull the latest version of the plugin
git submodule init
git submodule update
# commit the added submodule config and the pointer to the current version
git commit ~/.gitmodules ~/vendor/plugins/myplugin
In order to remove a submodule you must
Delete the relevant line from the .gitmodules file.
Delete the relevant section from .git/config.
Run git rm --cached path_to_submodule (no trailing slash).
Commit and delete the now untracked submodule files.
If you need to enable sudo access on a remote server (or any machine for that matter) but really don’t want to have to enter your password everytime, you can disable the password prompting. I combine this with adding my public ssh key so I can just get on with things, and not have to remember a million and one passwords.
rob@mail:~$ sudo cat /etc/sudoers
# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# User privilege specification
root ALL=(ALL) ALL
rails ALL=(ALL) ALL
rob ALL=(ALL) NOPASSWD: ALL
You can also fine grain this to disable the password prompt only for particular scripts if your user only really performs a few actions.