Integration Tests in Python with before_requests and session management

I have been developing in Python for roughly 5 months now and have learned a lot, not just about Python but also better practices in programming in general. 

Recently, I have been working on a project that involves logging in a user using a single sign-on cookie. Theoretically it’s as easy as 1) checking existence for said cookie; 2) unsigning the secured cookie; 3) if session doesn’t exist, set session and continue; 4) If cookie fails checks, redirect user to log in. The issue (for me at least) was trying to figure out how to write an integration test that simply checked to make sure the right template was used in the flask end-point I was testing.

Here’s the code

Happy hunting!


Working with Meteor JS and the bootstrap3-wysihtml5 meteorite package

Recently I have started working on a small Meteor JS application (https://github.com/dennismonsewicz/meteor-cms-bootstrap-3) which is going to be a small CMS that will power my personal website (at least the blogging aspect).

When working with Meteor there are a ton of great third party packages that you can plug and play with (thanks to Meteorite). One of them in particular that I was playing around with is the bootstrap3-wysiwyg package (https://atmospherejs.com/package/bootstrap3-wysihtml5).

I kept running into a problem where if I had content that already existed in the database, the wysiwyg editor wouldn’t populate with the existing content.

This is how I fixed it:

I am using a couple of other 3rd party meteorite packages to aid in building out my edit form, but you get the gist.


Rails 4: Working with Strong Parameters with Dynamic Forms

My development path has finally brought me to the avenue of Rails 4 and Ruby 2.1. The land of turbolinks, strong parameters and swift binary coding…

Now that I have tried to be a little poetic, let me get to the point of this blog post.

I am working on a project that calls for a user to dynamically add items to a form (by clicking on an add more link). Everything works as expected (on the front end), but strong parameters certainly did not like this idea. Here is how I solved the issue(s) I was having.





The focal point of this post is more in the view and controller. If you will notice in the code example above, we are setting the child index of the nested attributes with the current time.

If you were to use the traditional way of accepting these attributes with strong params, Rails would kick out the line_items hash. To allow for a dynamic form submission with a nested form, you have to use whitelist the entire line_items_attributes hash because we are dynamically setting the child_index.

From the Rails documentation: “Imagine a scenario where you want to whitelist an attribute containing a hash with any keys…” Rails Guide: Strong Params

Happy Hunting!


Rails 3: Back to basics with attr_accessible

Recently I was working on a project that contained a few *security flaws* in allowing all columns for a particular model to be accessed via forms in the application.

To rectify the issue, we not only needed to have a better management of setting associations, but also fixing potential injection problems. 

What is attr_accessible?
attr_accessible allows you to specify which attributes of a model can be altered via mass-assignment (update_attributes(attrs) or new(attrs))

Let’s take a look at an example.

In the above example, the form is opened up to allowing the admin flag to be submitted. What if the user being created isn’t supposed to be an admin? 

Let’s look at an example fixing this mass-assignment security hole:

The above shows us having better control in the application of setting the admin flag instead of allowing it to be maliciously set via HTTP requests. This security flaw has forced the Rails community to develop (in Rails 4) a new way of mass assigning attributes using Strong Parameters

This exercise was beneficial to me and the team I work with to button up any other security holes the app may be vulnerable too. Hope this helps!

Happy hunting!


Devise: Fast User Switching using a custom Authentication Strategy

Recently, my company needed a way to allow for users with a certain Access Control to log in (or impersonate) another user.

To be able to keep up with the original user, checking to see if the original user has access to the given user they would like to impersonate and signing in the user for impersonation, we came up with the following strategy for Warden.

Happy hunting!


Felis: Lightweight API Wrapper for Emma.com APIs

A year ago I wrote two API wrappers for Emma (The email marketing company located in Nashville, TN). One was in PHP, the other, Ruby. 


I decided to rewrite it in a different light. Felis is a lightweight wrapper that offers 4 simple methods to easily build integration into any Ruby/Rails app.

Check out Felis here: https://github.com/dennismonsewicz/felis

Happy hunting!


Active Admin, Kaminari and Rails boot up

Active Admin is an extremely nice tool when you need to have a quick ‘plug & play’ CRUD to give to admins to help administer a website.

One of the problems I kept running into was that every time my Rails server booted up (locally, production, etc), was that Kaminari (Rails gem for pagination - used by Active Admin; https://github.com/amatsuda/kaminari) would run through each registered Active Admin model and would attempt to override any page scope (by default Kaminari uses the method name of page when referring to pagination with a model and its results).

The problem looks like this (check your rails log during bootup):

To fix this issue simply do the following:

Happy Hunting!


Power in the context &block

Let me preface this post by stating that I am fairly new to the world of TDD and everything it encompasses.

In learning how to write tests, what to test and making sure my tests are performing correctly, one thing that helps [me] as well as reading others tests is using the context block in Rspec.

Context blocks help keep you’re tests clear and concise and when you are working in a big team, it helps to quickly identify what your specifically trying to test.

Happy testing!

Tags: rspec rails tdd

Rails 3 and modifying the link_to helper

One of the most recent applications I have been working on is an OAuth/Subscription Management/Product Store/User Management app. So far things have been interesting with trying to get every other app to play nicely with the way the internal engineering team has had to modify the OAuth system, but so far so good.

Within this application, we use an identifier in the URL titled client_id (http://url.com/hello?client_id=FANCY_CLIENT_ID_HERE). Upon entering the site, the application takes the client_id and sets the id in a session variable that is used to switch on/off branding (depending on which product or client you came in through). 

One of the annoyances we kept running into, is having to add the client_id to all of our link_to methods. So, today, I came up with the following:

  def link_to(*args, &block)
    args[1] = params[:client_id].present? ? "#{args[1]}?client_id=#{params[:client_id]}" : args[1]

You place the above method in your ApplicationHelper and Rails will know to pick it up from your application stack and not from the helpers available in the Rails Gem.

Happy Ruby’ing!


Working with Rails Flash Messages

Today, I kept running into a peculiar issue with Flash messages without a redirect inside of my Rails controllers.

When writing flash messages with redirects, you typically write something like this:

flash[:notice] = "Your fancy flash message here"
redirect_to your_fancy_path_here

This is how you get around displaying flash messages when rendering inside of a controller:

flash.now[:notice] = "Your fancy flash message here"
render :partial => 'path/to/partial'

Obviously, in your partial, you would display the flash message. By using the flash.now syntax, the message will only stay active with the rendering of the partial, and will not stay with the user if the user navigates to a secondary page.

Happy Coding!