Creating a Mechanize redirects log

1 In this post, we will see how to create a redirects log to mechanize library. Mechanize is following redirects, but what if I want to know which pages it visited? It is simple and easy to add redirects logs to mechanize. ===================READ MORE=================== <a href="http://ruby-doc.org/stdlib/libdoc/net/http/rdoc/classes/Net/HTTP.html">Net::HTTP</a> is a library provides your program functions to access WWW documents. You can use it to send GET or POST requests. You can read the response and take an action depending on the response. The problem you may face is that if the response is 301 Redirect, then you should follow redirects yourself. The response body will be like the following: <pre name="code" class="html"> <html><body>You are being <a href="http://localhost:3000/user_sessions/new">redirected</a>.</body></html></pre> A lot of work :( <a href="http://mechanize.rubyforge.org/mechanize/">Mechanize</a> library is used for automating interaction with websites. It follows redirects, can follow links, and submit forms. You can also define the redirection_limits in case it will get in a too long redirections path. While I was using mechanize, I needed to know the pages it visited while redirects. Unfortunately it wasn't supported. However, it wasn't hard to add it. Now, lets add our sugar... I will add it to mechanize version 0.9.3. We will play around lib/www/mechanize.rb file First, lets add redirects_log attribute accessor around line#85  <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <pre name="code" class="ruby"> attr_accessor :scheme_handlers attr_accessor :redirection_limit attr_accessor :redirects_log</pre> And lets initialize this array in Mechanize initialize method <pre name="code" class="ruby"> @redirects_log = []</pre> Then modify around line#550 to add the visited page to our redirects_log array <pre name="code" class="ruby"> elsif res_klass <= Net::HTTPRedirection return page unless follow_redirect? log.info("follow redirect to: #{ response['Location'] }") if log @redirects_log << response['Location'] from_uri = page.uri </pre> Finally, we can read the redirects logs <pre name="code" class="ruby"> agent.redirects_log</pre> It is simple and easy. That is the honey of the open source community :) 2

2010-03-07T06:44:32Z

true

Ruby, Rails,mechanize

2010-03-07T11:44:32Z

2010/2/28/creating-a-mechanize-redirects-log

1 Most of inventory applications have the same models and functionalities. Most of them should have shops, products, orders and line items. They need also to handle order payment status and fulfillment status. The products stock status is also a common requirement in most of them. <a href="http://www.shopify.com/">Shopify</a> handles all of that overhead and can do all of that for you. You won't need to handle this work every time. You can build your complete shop in just 2 minutes. Shop owners can create their shops, add products and product variants. Then shopify partners can create applications to integrate with the shop. <meta content="text/html; charset=utf-8" http-equiv="content-type" /> <a href="http://api.shopify.com/">Shopify API</a> is an XML API that allows applications to integrate with Shopify via <a href="http://en.wikipedia.org/wiki/Representational_State_Transfer">REST</a>ful actions using verbs (GET/POST/PUT/DELETE). ===================READ MORE=================== The Shopify API lets you access a Shopify store from your own application. You can have many applications integrated with your shop store. It will be easy to integrate with the store through the XML REST convention. Shopify supports Rails applications to integrate with it. You will need to install <a href="http://github.com/shopify/shopify_app">Shopify_app</a> plugin and <a href="http://github.com/Shopify/shopify_api">ShopifyAPI</a> gem for integration. <a href="http://github.com/shopify/shopify_app">Shopify app</a> is a rails plugin that generates basic login controller for authentication. <a href="http://github.com/Shopify/shopify_api">ShopifyAPI</a> is a lightweight gem for accessing the Shopify admin REST web services. ShopifyAPI can easily fetch orders and products using  <meta content="text/html; charset=utf-8" http-equiv="content-type"><a href="http://api.rubyonrails.org/classes/ActiveResource/Base.html">ActiveResource</a> as the following: </meta> <meta content="text/html; charset=utf-8" http-equiv="content-type" /> <pre class="ruby" name="code"> products = ShopifyAPI::Product.find(:all) orders = ShopifyAPI::Order.find(:all)</pre> You can also create, update or delete shopify resources using ActiveResource. <pre class="ruby" name="code"> #create product product = ShopifyAPI::Product.create(:body => "iphone", :title => "iphone by Apple", :vendor => "Burton") #update product title product.title = "Apple iphone" product.save #delete product product.destroy</pre> <meta content="text/html; charset=utf-8" http-equiv="content-type" /> This post just provides a fast introduction about shopify, shopify API, their shopify_app plugin and shopifyAPI gem. For more detailed information, check their official documentations. 3

2010-03-02T07:33:00Z

true

ruby, rails, ActiveResource, shopify,rest

Shopify API overview

2010-03-02T13:11:09Z

2010/3/2/shopify-api-overview

1 Introduction Background Since the appearance of smart-phones, mobile development has been done in separate islands, with each island having it's own set of traditions and languages, "Objective-C", "Java", ".Net"...... So the demand for a cross platform technologies has increased, and indeed a solutions emerged, in this article I'm going to explore the main three technologies out there, "rhodes", "PhoneGap", "Titanium Appcelerator". How it works? Despite the fact that each smart phone speaks a totally different language than others, they share one great advantage, that's they all have a web browser, so they all understand HTML, CSS and Javascript. So, this is the entry point for any technique targeting cross-platform, all of them are frameworks target the smart phone's web browser, but they differ in details, which we'll be discussing later. ===================READ MORE=================== Advantages - Write in familiar web development technologies, instead of learning about each framework. - "Write once run every where" ( actually this not how things happens, most of the time, it's 'write once, debug every where' ). So, no steep learning curve for each platform, and no extra development time for porting to each platform, only a very small overhead for deployment on different platforms. Disadvantages - More suitable for data oriented applications, but least effective in rich multimedia applications. - No support for gaming. - Lower performance profile compared with native technologies.   Technical Comparison Development framework: Rhodes: Hosts a Ruby on Rails framework, which have views, controllers and models, but lighter weight than desktop framework, so, a light weight rails server runs under the hoods, and a html, javascript web pages is viewed inside a browser, so that this framework is much more easier for rails developer to grasp. PhoneGap, Titanium: uses html, css and javascript, with application logic hosted inside a "WebView" control, but don't mix this with normal web applications, as normal web applications don't have access to the native functions such as Camera, contacts, geolocation.....etc, but PhoneGap and Titanium compiles as normal application and hosts the code inside a WebView control so that they can access native functions through javascript bridges. Tools Rhodes: Comes with a gem that's used for building and packaging of your applications, and also have a web tool to accomplish these tasks. PhoneGap: Depends on native development tools shipped with each framework SDK, xCode template for iPhone, Eclipse plugin for blackberry... Titanium: Have a very pleasant and powerful IDE for creating, packaging and launching of your applications. User experience Rhodes: Provides complete set of Native controls and styling through CSS to give the end user the same look 'n feel of native applications. PhoneGap: Does not provide native controls, and lets it up to you to customize the look of your application. Titanium: Provides some native controls but have less support than Rhodes for native controls. Supported Devices Rhodes: Supports iPhone, BlackBerry, Android, Windows Mobile and Symbian. PhoneGap: Supports iPhone, BlackBerry and Android. Titanium: Supports iPhone and Android, and there exist plans for support for other devices. License Rhodes: Commercial license for $500 per project. PhoneGap: Open source and free. Titanium: Open source and free while in beta phase, but when released will be commercial.   Summary Cross-platform mobile frameworks, is only a trial to give the same functionality using the same code, when deployed on different platforms, but don't support advanced graphics features, as Gaming and extensive multimedia needs, and is the optimum choice when it comes to data oriented applications. Although PhoneGap is free and open source, it lacks the native look 'n feel supported by other frameworks, and Rhodes supports larger number of Devices, but Titanium have better support and tools than both. 5

2010-02-10T11:11:10Z

true

mobile, iPhone, Android, Rhodes, PhoneGap, Titanium Appcelerator

Cross-Plateform mobile applications, a dream becomes reality!

2010-03-02T12:33:51Z

2010/2/10/cross-plateform-mobile-applications-a-dream-becomes-reality

1 In previous rails versions, to prevent cross-site scripting, the h helper method must be called explicitly to escape the output to the response body. The <a href="http://github.com/nzkoz/rails_xss">rails_xss</a> plugin replaces the default ERB template handlers with eruibs, and switches the behavior to escape by default rather than requiring you to escape. This behavior is consistent with Rails 3.0. Install <a href="http://github.com/nzkoz/rails_xss">rails_xss </a>using the following commands: <pre name="code" class="ruby"> sudo gem install erubis ruby script/plugin install git://github.com/NZKoz/rails_xss.git </pre> ===================READ MORE=================== By default a string is considered unsafe and is escaped by rails. If you have your own helpers you should tell Rails that these strings are safe using html_safe! method. If you want to display the string as HTML code instead of escaping it you just call html_safe! on the string object. As an example before installing <a href="http://github.com/nzkoz/rails_xss">rails_xss</a>: <pre class="ruby" name="code"> <%= "<h1>Hello, World!</h1>" %> # not escaped <%=h "<h1>Hello, World!</h1>" %> # escaped</pre> but after installing rails_xss by default a string is considered unsafe and will be escaped <pre name="code" class="ruby"> <%= "<h1>Hello, World!</h1>" %> # escaped <%= "<h1>Hello, World!</h1>".html_safe! %> # not escaped <%= raw "<h1>Hello, World!</h1>" %> # not escaped </pre> This helps in escaping any user-entered data in your application like comments. More information about rails_xss can be found at <a href="http://github.com/nzkoz/rails_xss">rails_xss</a> This escaping behavior will be painful if your application contains user-entered data, but from trusted sources like a blog. A blog contains many places that you don't want this behavior to be the default action. You will need to call html_safe! method in all the places you emit code to the view through strings. This behavior can be altered by adding a class method in ActiveRecord::Base class that will mark all the specified columns in a model as safe. This will make all blog models safe, and we won't need to call html_safe! every where in the views. In the config/initializers directory create "html_safe_attributes.rb" file; this file will be loaded every time you start the server. First we extend the ActiveRecord::Base class with the module that will contain our html_safe_attributes class method. <pre class="ruby" name="code"> class ActiveRecord::Base def self.inherited_with_html_safe_attributes(klass) inherited_without_html_safe_attributes(klass) klass.extend(HTMLSafeAttributes) end class <<self alias_method_chain :inherited, :html_safe_attributes end end </pre> <div> Then we write our HTMLSafeAttributes module:</div> <pre class="ruby" name="code"> module HTMLSafeAttributes def html_safe_attributes(*attrs) cols = attrs cols = columns.select { |col| col.type == :string || col.type == :text }.map(&:name) if attrs.first == :all cols.each do |attr| class_eval <<-STRING def #{attr} read_attribute(:#{attr}).html_safe! end STRING end end end class NilClass def html_safe! nil end end</pre> We enhanced the NilClass with html_safe! because a column value may be nil, and this will throw an exception in the read_attribute method. Now inside a blog model you specify your safe attributes, or you specify :all to mark all string in the model as safe. <pre class="ruby" name="code"> class BlogPost < ActiveRecord::Base html_safe_attributes :all end</pre> Any column whose type is string or text will be marked as safe. 3

2010-02-03T16:16:59Z

true

rails, xss

Prevent cross-site scripting in rails-2.3.5 using rails_xss plugin

2010-02-17T11:28:50Z

2010/2/3/prevent-cross-site-scripting-in-rails-2-3-5-using-rails_xss-plugin

1 If you used page caching in a site that implements RESTful interface, you may face a problem. You could have multiple actions that share a single URL with different HTTP methods. For example, showing a document is served at /documents/1, while updating the same document is also at /documents/1. When I'm trying to update a document, the request is something like PUT /documents/1 If your Apache is not well configured, it may respond with a cached file at /documents/1.html. This is wrong because this file should be served for GET requests only. In fact, POST, PUT and DELETE actions should never be cached because they change server state. Investigating in this issue, I found the following snippet at my .htaccess file. ===================READ MORE===================     # Conditions for fastcgi     RewriteRule ^$ index.html [QSA]     RewriteRule ^([^.]+)$ $1.html [QSA]     RewriteCond %{REQUEST_FILENAME} !-f     RewriteRule ^(.*)$ dispatch.fcgi [QSA,L] To solve this problem I changed a line and added a new line to make it like this     # Conditions for fastcgi     RewriteRule ^$ index.html [QSA]     RewriteRule ^([^.]+)$ $1.html [QSA]     RewriteCond %{REQUEST_FILENAME} !-f [OR]     RewriteCond %{THE_REQUEST} !^GET     RewriteRule ^(.*)$ dispatch.fcgi [QSA,L] This allows a request to served from file system only when the request is a GET request. This resolved the problem. 3

2010-02-03T08:49:38Z

true

ruby, rails, apache, caching, htaccess

Skipping cache for POST actions in Apache

2010-02-14T12:02:42Z

2010/2/3/skipping-cache-for-post-actions-in-apache