• Shortcuts : 'n' next unread feed - 'p' previous unread feed • Styles : 1 2

» Publishers, Monetize your RSS feeds with FeedShow:  More infos  (Show/Hide Ads)


Date: Sunday, 19 Jan 2014 23:00

You may notice a little blog facelift. The look-and-feel is now in line with the site update I published at the beginning of December.

But what you can see is just the tip of the iceberg. The design update has been the excellent excuse to migrate the blog from WordPress to Jekyll. Switching to a static site was not trivial and this means the comments are now powered by Disqus, there are no more hundreds of category and tag archives, and some posts may looks a little bit weird due to the migration from WordPress to Markdown.

Apart from the inevitable compromises imposed by a static site generator, I'm very happy with the final result. I can now write posts in Markdown (probably the primary reason why I love to use Jekyll), create and edit my posts offline, version the content and the layout, and edit the site with a text editor.

Maintaining the blog layout in sync with the main site has been a non-trivial task for ages, due to the vary different environments the two sites has been hosted on. But now, I can share the same SCSS templates and easily track down the changes using git. WordPress modules and themes didn't allow the same flexibility.

I've redesigned the blog template a little bit to enhance the readability. The font is a larger than the site and the content is the leading element. No more sidebars or distractions.

Blog design v2 vs v3

As I said, the migration was not painless. If you came across any article with invalid formatting, please report it to me. Thanks, and enjoy the new blog!

Author: "--"
Send by mail Print  Save  Delicious 
Date: Sunday, 19 Jan 2014 23:00

You may notice a little blog facelift. The look-and-feel is now in line with the site update I published at the beginning of December.

But what you can see is just the tip of the iceberg. The design update has been the excellent excuse to migrate the blog from WordPress to Jekyll. Switching to a static site was not trivial and this means the comments are now powered by Disqus, there are no more hundreds of category and tag archives, and some posts may looks a little bit weird due to the migration from WordPress to Markdown.

Apart from the inevitable compromises imposed by a static site generator, I'm very happy with the final result. I can now write posts in Markdown (probably the primary reason why I love to use Jekyll), create and edit my posts offline, version the content and the layout, and edit the site with a text editor.

Maintaining the blog layout in sync with the main site has been a non-trivial task for ages, due to the vary different environments the two sites has been hosted on. But now, I can share the same SCSS templates and easily track down the changes using git. WordPress modules and themes didn't allow the same flexibility.

I've redesigned the blog template a little bit to enhance the readability. The font is a larger than the site and the content is the leading element. No more sidebars or distractions.

Blog design v2 vs v3

As I said, the migration was not painless. If you came across any article with invalid formatting, please report it to me. Thanks, and enjoy the new blog!

Author: "--"
Send by mail Print  Save  Delicious 
Date: Thursday, 14 Nov 2013 22:23

Working for a company that sells SSL certificates, I noticed that this field is often very confusing when you approach it for the first time. One of the most unclear topic is the number of available certificate types. In this article I'll quickly explain the differences between the various types you may want to use to secure a website.

To make it simple, you can group SSL certificates by validation level or secured domains/hostnames.

SSL Certificates by Validation Level

The validation level determines the method adopted by the Certificate Authority to confirm the identity of the certificate applicant.

A certificate offers the same level of security and protection regardless the validation level. However, some businesses may require a specific validation level in order to apply for certain services. For example, a payment system may force a customer to purchase a extended validation certificate instead of a domain validated or organization validated certificate to ensure the legal existence of the company operating the business.

Domain Validated SSL Certificates

The Domain Validated SSL Certificate validates the domain is registered and someone with admin rights is aware of and approves the certificate request.

The validation process is normally performed via email or DNS.

  • Via email, the CA sends an approval email to one of the administrative email recipients for the certificate. The user validates the ownership by clicking on a link included in the email.
  • Via DNS, the user is requested to configure a special DNS according to the CA instructions.

The order normally takes from a few minutes to a few hours.

The Domain Validated SSL certificate is the most common SSL certificate type because it's fast to purchase. This validation type is sufficient for the majority of businesses and cheaper compared to Company or Extended validations.

If the certificate is valid and signed by a trusted authority, the browsers indicate a successfully secured HTTPS connection.

Organization Validated SSL Certificates

The Organization Validated SSL Certificate (OV certificate) validates the domain ownership, plus organization information included in the certificate such as name, city, state and country.

The validation process is similar to the domain validated certificate, but it requires additional documentation to certify the company identity.

The order can take from a few hours to a few days, due to the company validation process.

The Organization Validated SSL Certificates display the company information in the certificate details.

Extended Validation SSL Certificates

The Extended Validation SSL Certificate (EV certificate) requires an extended validation of the business. It validates domain ownership and organization information, plus the legal existence of the organization. It also validates that the organization is aware of the SSL certificate request and approves it.

The validation requires documentation to certify the company identity plus a set of additional steps and checks.

The order can take from a few days to a few weeks, due to the extended validation process.

The Extended Validation SSL Certificates are generally identified with a green address bar in the browser containing the company name.

Extended Validation (EV) "Wildcard" SSL certificates don't exist

The Extended Validation (EV) SSL certificates provide a higher level of assurance compared to the other types of SSL certificates. In order to ensure that EV SSL certificates are not misused after issuance, the regulatory body governing the issuance of EV SSL certificates requires the validation of every hostname assigned to the certificate. Therefore, it's not possible to purchase a wildcard EV SSL certificate.

SSL Certificates by Secured Domains

An SSL certificate is associated to one or more subdomains belonging to one or more domains. The list of secured subdomains is attached to the certificate when it is issued and restricts the scope of a certificate.

Domains or subdomains not included in the list are not secured by the certificate. Trying to use the certificate for a subdomain outside its scope will generate a security warning in the browser.

Single-name SSL Certificates

Single-name SSL certificates protects a single subdomain (hostname). For example, if you purchase a certificate for www.example.com it will not secure mail.example.com.

There is only one common exception. Certificate authorities normally release certificates for the root domain (example.com) if you purchase a single-name certificate for the www hostname (www.example.com). This is not a standard, check the provider documentation.

Wildcard SSL Certificates

Single-name SSL certificates protects an unlimited number of subdomains of a single domain. For example, if you purchase a certificate for *.example.com if will secure foo.example.com, bar.example.com, etc. It will not secure foo.else.example.com.

Wildcard certificates are forbidden for Extended Validation certificates. See the section above about Extended Validation for more information.

Multi-Domain SSL Certificates

Multi-domains SSL certificates protects different domains with a single certificate. The number of domains included depends on the certificate authority. You can normally secure a combination of different subdomains from different domains.

Shared SSL Certificates

Shared SSL certificate are normally offered by hosting companies as a way to secure websites under a specific domain name. For example, in Heroku each application is provided with a .herokuapp.com hostname. Heroku offers a free shared certificate you can enable as long as your app is reachable with the shared hostname.

You can think a shared SSL certificate as a wildcard certificate purchased by a hosting company and made available to your app as long as they are hosted under the shared domain name provided by the hosting company itself.

Security

It's important to remember that the validation level and the number of secured domains don't affect the security level offered by an SSL certificate. All certificates work with the following encryption principle.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Thursday, 14 Nov 2013 22:23

Working for a company that sells SSL certificates, I noticed that this field is often very confusing when you approach it for the first time. One of the most unclear topic is the number of available certificate types. In this article I'll quickly explain the differences between the various types you may want to use to secure a website.

To make it simple, you can group SSL certificates by validation level or secured domains/hostnames.

SSL Certificates by Validation Level

The validation level determines the method adopted by the Certificate Authority to confirm the identity of the certificate applicant.

A certificate offers the same level of security and protection regardless the validation level. However, some businesses may require a specific validation level in order to apply for certain services. For example, a payment system may force a customer to purchase a extended validation certificate instead of a domain validated or organization validated certificate to ensure the legal existence of the company operating the business.

Domain Validated SSL Certificates

The Domain Validated SSL Certificate validates the domain is registered and someone with admin rights is aware of and approves the certificate request.

The validation process is normally performed via email or DNS.

  • Via email, the CA sends an approval email to one of the administrative email recipients for the certificate. The user validates the ownership by clicking on a link included in the email.
  • Via DNS, the user is requested to configure a special DNS according to the CA instructions.

The order normally takes from a few minutes to a few hours.

The Domain Validated SSL certificate is the most common SSL certificate type because it's fast to purchase. This validation type is sufficient for the majority of businesses and cheaper compared to Company or Extended validations.

If the certificate is valid and signed by a trusted authority, the browsers indicate a successfully secured HTTPS connection.

Organization Validated SSL Certificates

The Organization Validated SSL Certificate (OV certificate) validates the domain ownership, plus organization information included in the certificate such as name, city, state and country.

The validation process is similar to the domain validated certificate, but it requires additional documentation to certify the company identity.

The order can take from a few hours to a few days, due to the company validation process.

The Organization Validated SSL Certificates display the company information in the certificate details.

Extended Validation SSL Certificates

The Extended Validation SSL Certificate (EV certificate) requires an extended validation of the business. It validates domain ownership and organization information, plus the legal existence of the organization. It also validates that the organization is aware of the SSL certificate request and approves it.

The validation requires documentation to certify the company identity plus a set of additional steps and checks.

The order can take from a few days to a few weeks, due to the extended validation process.

The Extended Validation SSL Certificates are generally identified with a green address bar in the browser containing the company name.

Extended Validation (EV) "Wildcard" SSL certificates don't exist

The Extended Validation (EV) SSL certificates provide a higher level of assurance compared to the other types of SSL certificates. In order to ensure that EV SSL certificates are not misused after issuance, the regulatory body governing the issuance of EV SSL certificates requires the validation of every hostname assigned to the certificate. Therefore, it's not possible to purchase a wildcard EV SSL certificate.

SSL Certificates by Secured Domains

An SSL certificate is associated to one or more subdomains belonging to one or more domains. The list of secured subdomains is attached to the certificate when it is issued and restricts the scope of a certificate.

Domains or subdomains not included in the list are not secured by the certificate. Trying to use the certificate for a subdomain outside its scope will generate a security warning in the browser.

Single-name SSL Certificates

Single-name SSL certificates protects a single subdomain (hostname). For example, if you purchase a certificate for www.example.com it will not secure mail.example.com.

There is only one common exception. Certificate authorities normally release certificates for the root domain (example.com) if you purchase a single-name certificate for the www hostname (www.example.com). This is not a standard, check the provider documentation.

Wildcard SSL Certificates

Single-name SSL certificates protects an unlimited number of subdomains of a single domain. For example, if you purchase a certificate for *.example.com if will secure foo.example.com, bar.example.com, etc. It will not secure foo.else.example.com.

Wildcard certificates are forbidden for Extended Validation certificates. See the section above about Extended Validation for more information.

Multi-Domain SSL Certificates

Multi-domains SSL certificates protects different domains with a single certificate. The number of domains included depends on the certificate authority. You can normally secure a combination of different subdomains from different domains.

Shared SSL Certificates

Shared SSL certificate are normally offered by hosting companies as a way to secure websites under a specific domain name. For example, in Heroku each application is provided with a .herokuapp.com hostname. Heroku offers a free shared certificate you can enable as long as your app is reachable with the shared hostname.

You can think a shared SSL certificate as a wildcard certificate purchased by a hosting company and made available to your app as long as they are hosted under the shared domain name provided by the hosting company itself.

Security

It's important to remember that the validation level and the number of secured domains don't affect the security level offered by an SSL certificate. All certificates work with the following encryption principle.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Wednesday, 20 Mar 2013 16:45

Whois is an intelligent — pure Ruby — WHOIS client and parser. It provides a flexible and programmable API to query WHOIS servers and look up IP, TLD, and domain WHOIS information. This library was developed to power RoboWhois, RoboDomain and, more recently, DNSimple.

Let's keep this announcement short and simple: Whois 3.0 has been released today!

Developers tend to assign fancy names to major releases, so I will. For the purpose of this article, I'll call this release Whois 3.

Changes

Whois 3 is the result of about 6 month of work. It contains several improvements in addition to an incredible amount of tweaks and updates. If you don't believe me, you can have a look at the CHANGELOG and you'll immediately realize that the Release 3.0 counts more than 50 entries.

The most notable change that will probably affect a few users is the minimum Ruby requirement. Whois 3 no longer supports Ruby 1.8.7 and the minumum Ruby version is now Ruby 1.9.2. With Ruby 2.0 released, it's time to move forward.

Query Handler

One of the most important features is the introduction of the query handler.

Whois::Server::Adapters::Base.query_handler.class
# => Whois::Server::SocketHandler

The query handler is responsible for the low-level connection between the library and the external WHOIS source. The default query handler, as the class name suggests, is a socket-based handler. It opens a connection to the specified server, writes a query and reads a response that in most cases is the final WHOIS record.

So far so good. But what if you want to use a proxy? Or if you want to be able to use an async socket connection? Before Whois 3 the only way was to monkey patch the library. Today, you simply need to write your own handler and configure the library to use it.

class MyHandler
  def call(query, *args)
  # ...
  end
end

Whois::Server::Adapters::Base.query_handler = MyHandler

# This request will use your custom handler
Whois.whois "..."

Another good case is a Test handler to be used in a test environment. A Test handler would be a simple and effective replacement for all the stubs and mocks across our application spec suite. Also, it will ensure no real socket connection is performed outside our application when our test suite is running.

Non-Deep querying

The support for Non-Deep queries is another long awaited feature. You can now skip deep queries for thin providers passing the :referral => false option.

c = Whois::Client.new(referral: false)
c.lookup "google.com"

The option also works in the command line.

$ ruby-whois google.com --no-referral

Aknowledgements

Whois 3 was made possible by the contributions of several contributors and reporters. I would also thank you DNSimple for sponsoring the development of the library.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Wednesday, 20 Mar 2013 16:45

Whois is an intelligent — pure Ruby — WHOIS client and parser. It provides a flexible and programmable API to query WHOIS servers and look up IP, TLD, and domain WHOIS information. This library was developed to power RoboWhois, RoboDomain and, more recently, DNSimple.

Let's keep this announcement short and simple: Whois 3.0 has been released today!

Developers tend to assign fancy names to major releases, so I will. For the purpose of this article, I'll call this release Whois 3.

Changes

Whois 3 is the result of about 6 month of work. It contains several improvements in addition to an incredible amount of tweaks and updates. If you don't believe me, you can have a look at the CHANGELOG and you'll immediately realize that the Release 3.0 counts more than 50 entries.

The most notable change that will probably affect a few users is the minimum Ruby requirement. Whois 3 no longer supports Ruby 1.8.7 and the minumum Ruby version is now Ruby 1.9.2. With Ruby 2.0 released, it's time to move forward.

Query Handler

One of the most important features is the introduction of the query handler.

Whois::Server::Adapters::Base.query_handler.class
# => Whois::Server::SocketHandler

The query handler is responsible for the low-level connection between the library and the external WHOIS source. The default query handler, as the class name suggests, is a socket-based handler. It opens a connection to the specified server, writes a query and reads a response that in most cases is the final WHOIS record.

So far so good. But what if you want to use a proxy? Or if you want to be able to use an async socket connection? Before Whois 3 the only way was to monkey patch the library. Today, you simply need to write your own handler and configure the library to use it.

class MyHandler
  def call(query, *args)
  # ...
  end
end

Whois::Server::Adapters::Base.query_handler = MyHandler

# This request will use your custom handler
Whois.whois "..."

Another good case is a Test handler to be used in a test environment. A Test handler would be a simple and effective replacement for all the stubs and mocks across our application spec suite. Also, it will ensure no real socket connection is performed outside our application when our test suite is running.

Non-Deep querying

The support for Non-Deep queries is another long awaited feature. You can now skip deep queries for thin providers passing the :referral => false option.

c = Whois::Client.new(referral: false)
c.lookup "google.com"

The option also works in the command line.

$ ruby-whois google.com --no-referral

Aknowledgements

Whois 3 was made possible by the contributions of several contributors and reporters. I would also thank you DNSimple for sponsoring the development of the library.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Thursday, 06 Sep 2012 18:20

A pochi giorni di distanza dal rilascio di VMWare Fusion 5, Parallels, l’altro big player nel campo delle virtual machine per Mac OS X, ha annunciato la disponibilità di Parallels Desktop 8.

Parallels Desktop 8 per Mac OS X si presenta 30% più veloce rispetto ai predecessori nelle operazioni di avvio, suspensione e spegnimento delle virtual machine. Introduce il supporto al display Retina disponibile nelle nuove generazioni di Mac ed è la prima versione ufficialmente compatibile con Max OS X Mountain Lion, il nuovo sistema operativo Apple.

Parallels Desktop 8 è in vendita a 79.99€, la licenza d’aggiornamento costa invece 49,99€. Il software è scaricabile, anche in italiano, dal sito ufficiale.

Chiunque abbia acquistato una licenza di Parallels Desktop 7 dopo il 25 Luglio 2012 può usufruire di un aggiornamento gratuito.

Author: "Simone Carletti" Tags: "Software, macosx, macosx mountain lion, ..."
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 27 Mar 2012 10:13

The WHOIS is a query/response protocol that is widely used to query databases that hold information about internet resources such as domain names and IP address allocations.

Created in the 1980s, WHOIS began as a service used by Internet operators to identify individuals or entities responsible for the operation of a network resource on the Internet. The WHOIS service has since evolved into a tool used for many purposes.

Nowadays the WHOIS protocol is primarily used by registrants and users to query domain registrar databases to obtain domain name information and check domain name availability.

Specification

The NICNAME/WHOIS protocol was first described in RFC 812 in 1982 by Ken Harrenstien and Vic White of the Network Information Center at SRI International, and subsequently updated 3 years later in RFC 954.

The RFC 3912, published in 2004, is the latest and most significant update to the WHOIS protocol as of today. It renamed the NICNAME/WHOIS to WHOIS and introduced several updates intended to remove the information no longer applicable to the state of the Internet in 2004.

The RFC 3912 contains the essence of the WHOIS protocol specification.

A WHOIS server listens on TCP port 43 for requests from WHOIS clients. The WHOIS client makes a text request to the WHOIS server, then the WHOIS server replies with text content. All requests are terminated with ASCII CR and then ASCII LF. The response might contain more than one line of text, so the presence of ASCII CR or ASCII LF characters does not indicate the end of the response. The WHOIS server closes its connection as soon as the output is finished. The closed TCP connection is the indication to the client that the response has been received.

Whilst the RFC 3912 provides (very little) information about how a WHOIS query should work, it doesn't say anything at all about the content of a WHOIS server response. What about the syntax or the encoding?

Also, the WHOIS protocol lacks mechanisms for access control, integrity, and confidentiality.

As a result, in the years providers designed their own WHOIS server implementation. The proliferation of customized WHOIS protocols makes almost impossible the creation of an unique, standardized interface to query WHOIS servers and consume WHOIS responses.

Standardization

ICANN recently started a project that would eventually end up with the creation of a standardized WHOIS as a replacement for the current WHOIS protocol. This is an extremely ambitious project that unfortunately has a huge chance of failure due to the large adoption of the WHOIS protocol.

Replacing all existing WHOIS servers would requires an incredible effort and this is one of the reasons why similar projects such as RWhois and Whois++ have failed in the past.

ICANN is probably the only organization capable of start such kind of reorganization of the WHOIS protocol.

Current State

As of today, the WHOIS protocol is the de-facto "standard" for querying domain name information. The decision to expose or not a public WHOIS interface is completely up to the TLD maintainer.

For instance, the .COM and .DE TLDs provides a public WHOIS interface, the .ES TLD provides a private WHOIS interface while the .VA TLD doesn't provide any WHOIS interface. It means there's no way to get information about a .VA domain.

The WHOIS protocol is a TCP-based protocol designed to work on the port 43. This makes extremely difficult to perform a WHOIS query from a browser without relying on a server-side third party tool. In fact, client side JavaScript is not able to perform socket requests on port 43.

Because of this, every hosting company provides a custom web-based WHOIS tool to query WHOIS information. The majority of these tools is implemented using a WHOIS API service such as RoboWhois or DomainTools or using a WHOIS client. There are WHOIS clients in almost every programming language.

Disclaimer: I'm the author of RoboWhois.

Also, it's not unusual to find a WHOIS form directly on registry websites. This is the case, for example, of Denic.de for the .DE tld or Registro.it for the .IT tld. In several cases, the web-based registry form provides private information normally hidden in the public WHOIS interface, such as contact details.

This is an example of a GoDaddy WHOIS response using the TCP WHOIS interface. Notice the link to the web-based WHOIS interface.

Please note: the registrant of the domain name is specified
in the "registrant" field.  In most cases, GoDaddy.com, LLC
is not the registrant of domain names listed in this database.

Registrant:
   Simone Carletti

   Registered through: GoDaddy.com, LLC (http://www.godaddy.com)
   Domain Name: WEPPOS.COM

   Domain servers in listed order:
      NS1.DREAMHOST.COM
      NS2.DREAMHOST.COM
      NS3.DREAMHOST.COM

   For complete domain details go to:
   http://who.godaddy.com/whoischeck.aspx?Domain=WEPPOS.COM

There is also a plethora of web-based services that provide WHOIS information, normally mixed with other domain-related and networking details such as IP address, server location and reverse lookup. A large number of these services intentionally re-publishes WHOIS responses as web pages in order to gain visitors from search engines and promote affiliations or products.

For example, here's the result page for whois expedia.

Search results for whois expedia.com

In most cases, web-based WHOIS interfaces have been accused of front running domains. The best way to avoid your domain being registered by one of these services is to run WHOIS queries using the socket based WHOIS interface, use the maintainer web-based WHOIS service or make sure the service you want to use contains explicit information about domain name front running in the privacy policy or terms of service.

Resources

Despite WHOIS is a very simple protocol, the lack of a well-structured specification transforms it to one of the most complex and unforeseeing protocol to work with. It's impossible to cover all WHOIS topics into a single article and I will probably publish more posts in the future.

The following resources can help you to learn more about the WHOIS protocol, query a WHOIS server and consume WHOIS responses.

  • Wikipedia - the Wikipedia WHOIS article.
  • Whois - the most popular WHOIS commandline client.
  • Ruby Whois - a WHOIS client and parser in Ruby.
  • RoboWhois - a cloud-based web service that provides a RESTful API to access WHOIS records.
Author: "--"
Send by mail Print  Save  Delicious 
Date: Tuesday, 27 Mar 2012 10:13

The WHOIS is a query/response protocol that is widely used to query databases that hold information about internet resources such as domain names and IP address allocations.

Created in the 1980s, WHOIS began as a service used by Internet operators to identify individuals or entities responsible for the operation of a network resource on the Internet. The WHOIS service has since evolved into a tool used for many purposes.

Nowadays the WHOIS protocol is primarily used by registrants and users to query domain registrar databases to obtain domain name information and check domain name availability.

Specification

The NICNAME/WHOIS protocol was first described in RFC 812 in 1982 by Ken Harrenstien and Vic White of the Network Information Center at SRI International, and subsequently updated 3 years later in RFC 954.

The RFC 3912, published in 2004, is the latest and most significant update to the WHOIS protocol as of today. It renamed the NICNAME/WHOIS to WHOIS and introduced several updates intended to remove the information no longer applicable to the state of the Internet in 2004.

The RFC 3912 contains the essence of the WHOIS protocol specification.

A WHOIS server listens on TCP port 43 for requests from WHOIS clients. The WHOIS client makes a text request to the WHOIS server, then the WHOIS server replies with text content. All requests are terminated with ASCII CR and then ASCII LF. The response might contain more than one line of text, so the presence of ASCII CR or ASCII LF characters does not indicate the end of the response. The WHOIS server closes its connection as soon as the output is finished. The closed TCP connection is the indication to the client that the response has been received.

Whilst the RFC 3912 provides (very little) information about how a WHOIS query should work, it doesn't say anything at all about the content of a WHOIS server response. What about the syntax or the encoding?

Also, the WHOIS protocol lacks mechanisms for access control, integrity, and confidentiality.

As a result, in the years providers designed their own WHOIS server implementation. The proliferation of customized WHOIS protocols makes almost impossible the creation of an unique, standardized interface to query WHOIS servers and consume WHOIS responses.

Standardization

ICANN recently started a project that would eventually end up with the creation of a standardized WHOIS as a replacement for the current WHOIS protocol. This is an extremely ambitious project that unfortunately has a huge chance of failure due to the large adoption of the WHOIS protocol.

Replacing all existing WHOIS servers would requires an incredible effort and this is one of the reasons why similar projects such as RWhois and Whois++ have failed in the past.

ICANN is probably the only organization capable of start such kind of reorganization of the WHOIS protocol.

Current State

As of today, the WHOIS protocol is the de-facto "standard" for querying domain name information. The decision to expose or not a public WHOIS interface is completely up to the TLD maintainer.

For instance, the .COM and .DE TLDs provides a public WHOIS interface, the .ES TLD provides a private WHOIS interface while the .VA TLD doesn't provide any WHOIS interface. It means there's no way to get information about a .VA domain.

The WHOIS protocol is a TCP-based protocol designed to work on the port 43. This makes extremely difficult to perform a WHOIS query from a browser without relying on a server-side third party tool. In fact, client side JavaScript is not able to perform socket requests on port 43.

Because of this, every hosting company provides a custom web-based WHOIS tool to query WHOIS information. The majority of these tools is implemented using a WHOIS API service such as RoboWhois or DomainTools or using a WHOIS client. There are WHOIS clients in almost every programming language.

Disclaimer: I'm the author of RoboWhois.

Also, it's not unusual to find a WHOIS form directly on registry websites. This is the case, for example, of Denic.de for the .DE tld or Registro.it for the .IT tld. In several cases, the web-based registry form provides private information normally hidden in the public WHOIS interface, such as contact details.

This is an example of a GoDaddy WHOIS response using the TCP WHOIS interface. Notice the link to the web-based WHOIS interface.

Please note: the registrant of the domain name is specified
in the "registrant" field.  In most cases, GoDaddy.com, LLC
is not the registrant of domain names listed in this database.

Registrant:
   Simone Carletti

   Registered through: GoDaddy.com, LLC (http://www.godaddy.com)
   Domain Name: WEPPOS.COM

   Domain servers in listed order:
      NS1.DREAMHOST.COM
      NS2.DREAMHOST.COM
      NS3.DREAMHOST.COM

   For complete domain details go to:
   http://who.godaddy.com/whoischeck.aspx?Domain=WEPPOS.COM

There is also a plethora of web-based services that provide WHOIS information, normally mixed with other domain-related and networking details such as IP address, server location and reverse lookup. A large number of these services intentionally re-publishes WHOIS responses as web pages in order to gain visitors from search engines and promote affiliations or products.

For example, here's the result page for whois expedia.

Search results for whois expedia.com

In most cases, web-based WHOIS interfaces have been accused of front running domains. The best way to avoid your domain being registered by one of these services is to run WHOIS queries using the socket based WHOIS interface, use the maintainer web-based WHOIS service or make sure the service you want to use contains explicit information about domain name front running in the privacy policy or terms of service.

Resources

Despite WHOIS is a very simple protocol, the lack of a well-structured specification transforms it to one of the most complex and unforeseeing protocol to work with. It's impossible to cover all WHOIS topics into a single article and I will probably publish more posts in the future.

The following resources can help you to learn more about the WHOIS protocol, query a WHOIS server and consume WHOIS responses.

  • Wikipedia - the Wikipedia WHOIS article.
  • Whois - the most popular WHOIS commandline client.
  • Ruby Whois - a WHOIS client and parser in Ruby.
  • RoboWhois - a cloud-based web service that provides a RESTful API to access WHOIS records.
Author: "--"
Send by mail Print  Save  Delicious 
Date: Sunday, 05 Feb 2012 21:34

This article targets Rails ~> 3.2

The article was written as of Rails 3.2. The information contained in this page might not apply to different versions.

I have a very simple Rails 3.1 application, deployed on Heroku. Just after upgrading it to Rails 3.2, the deploy to Heroku stopped working properly.

More specifically, the rake asset:precompile task was failing during slug compilation.

       Your bundle is complete! It was installed into ./vendor/bundle
       Cleaning up the bundler cache.
-----> Writing config/database.yml to read from DATABASE_URL
-----> Preparing app for Rails asset pipeline
       Running: rake assets:precompile
       rake aborted!
       could not connect to server: Connection refused
       Is the server running on host "127.0.0.1" and accepting
       TCP/IP connections on port 5432?

       Tasks: TOP => environment
       (See full trace by running task with --trace)
       Precompiling assets failed, enabling runtime asset compilation
       Injecting rails31_enable_runtime_asset_compilation
       Please see this article for troubleshooting help:
       http://devcenter.heroku.com/articles/rails31_heroku_cedar#troubleshooting

The Heroku assets:precompile toubleshooting page contains several explanations, but none of these was my case. In fact, my application was working properly with Rails 3.1.

It turns out there are some changes in the Rails 3.2 initialization process that conflicts with Heroku slug compilation. The solution is very simple. All you have to do is to set the Rails 3.2 initialize_on_precompile configuration to false in your application.rb file.

config.assets.initialize_on_precompile = false

This option is new in Rails 3.2 and prevents the Rails environment to be loaded when the assets:precompile task is executed. Because Heroku precompile assets before setting the database configuration, you need to set this configuration to false or you Rails application will try to connect to an unexisting database.

       Your bundle is complete! It was installed into ./vendor/bundle
       Cleaning up the bundler cache.
-----> Writing config/database.yml to read from DATABASE_URL
-----> Preparing app for Rails asset pipeline
       Running: rake assets:precompile
-----> Rails plugin injection
       Injecting rails_log_stdout
       Injecting rails3_serve_static_assets
...

This configuration is also documented in the Precompiling Assets section of the new Rails 3.2 asset pipeline guide.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Sunday, 05 Feb 2012 21:34

This article targets Rails ~> 3.2

The article was written as of Rails 3.2. The information contained in this page might not apply to different versions.

I have a very simple Rails 3.1 application, deployed on Heroku. Just after upgrading it to Rails 3.2, the deploy to Heroku stopped working properly.

More specifically, the rake asset:precompile task was failing during slug compilation.

       Your bundle is complete! It was installed into ./vendor/bundle
       Cleaning up the bundler cache.
-----> Writing config/database.yml to read from DATABASE_URL
-----> Preparing app for Rails asset pipeline
       Running: rake assets:precompile
       rake aborted!
       could not connect to server: Connection refused
       Is the server running on host "127.0.0.1" and accepting
       TCP/IP connections on port 5432?

       Tasks: TOP => environment
       (See full trace by running task with --trace)
       Precompiling assets failed, enabling runtime asset compilation
       Injecting rails31_enable_runtime_asset_compilation
       Please see this article for troubleshooting help:
       http://devcenter.heroku.com/articles/rails31_heroku_cedar#troubleshooting

The Heroku assets:precompile toubleshooting page contains several explanations, but none of these was my case. In fact, my application was working properly with Rails 3.1.

It turns out there are some changes in the Rails 3.2 initialization process that conflicts with Heroku slug compilation. The solution is very simple. All you have to do is to set the Rails 3.2 initialize_on_precompile configuration to false in your application.rb file.

config.assets.initialize_on_precompile = false

This option is new in Rails 3.2 and prevents the Rails environment to be loaded when the assets:precompile task is executed. Because Heroku precompile assets before setting the database configuration, you need to set this configuration to false or you Rails application will try to connect to an unexisting database.

       Your bundle is complete! It was installed into ./vendor/bundle
       Cleaning up the bundler cache.
-----> Writing config/database.yml to read from DATABASE_URL
-----> Preparing app for Rails asset pipeline
       Running: rake assets:precompile
-----> Rails plugin injection
       Injecting rails_log_stdout
       Injecting rails3_serve_static_assets
...

This configuration is also documented in the Precompiling Assets section of the new Rails 3.2 asset pipeline guide.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Monday, 03 Oct 2011 09:49

Eloquent Ruby (US | UK | IT) is a book about the Ruby programming language that focuses on Ruby programming style by teaching you how to write your code as a real Rubyist.

Be prepared, this is an unconventional Ruby book. To use author's words:

This is a book about making that final leap, about absorbing the Ruby programming culture, about becoming truly fluent in Ruby. You need to absorb the cultural part of Ruby, to see how real Rubyist use the language to solve problems.

Learning Ruby is not difficult, start thinking in Ruby and becoming a Rubyist is the real challenge.


Structure

The book is divided into 4 parts. Each part is divided into chapters. The book counts 31 chapters and about 400 pages.

  1. The Basics
  2. Classes, Modules, and Blocks
  3. Metaprogramming
  4. Pulling It All Together

The first part covers some basic Ruby features in a way you normally won't read in any other Ruby reference. Ah, if I only had the Symbol chapter available when I started learning Ruby!

The second part covers Classes, Modules and Blocks and it explains how to use modules successfully, how to deal with inheritance, equality and operators. This is by far my most favorite section.

The third part is about Metaprogramming. Whilst the name of the section is technically correct, it can be misleading. If you are looking for a complete Ruby and Metaprogramming course, check out Metaprogramming Ruby (US | UK). This section covers common Ruby metaprogramming topic such as hooks, method_missing (a must read!) and monkey patching.

The fourth part wraps several topics all together and talks about creating and implementing a DSL in Ruby.

The book ends with a rich list of books about Ruby and programming in general. The list contains amazing Ruby titles like Ruby Best Practices (US | UK) or The Ruby Way Second Edition (US | UK), as well programming masterpieces like The Elements of Programming Style (US | UK). If you are looking for some inspiration about your next reading, you might probably find some there.

Requirements

This book assumes that you have a basic knowledge of the Ruby language. You don't need to be a Ruby master, but some advanced sections such as Metaprogramming and DSL may require you to stop for a moment and refresh or improve your specific knowledge of Ruby on that topic.

Don't expect this book to explain you the basic details of Ruby or its syntax, this is behind the scope of this publication. There are plenty of commented examples, but if you want to learn about a specific Ruby feature make sure you keep a reference like Programming Ruby or The Ruby Way handy.

Be ready to read printed source code: this book is full or Ruby code. At least the 50% of the pages contain code, making this book a valuable practical reference.

Plus

Eloquent Ruby is a very lightweight and pleasant reading. The colloquial tone is friendly and engrossing. The books has plenty of code snippets and it requires only a few days to read it from start to end.

Aside from being an excellent resource to help you thinking Ruby and programming in the Ruby way, this book constantly adopts a practical approach providing tons of examples to read. Every chapter ends with an In the Wild section containing examples extracted from real Ruby libraries, and a Wrapping up section that helps you to fix the concepts in mind.

I appreciated the focus on tests and the RSpec chapter. The most part of the examples are verified by tests, and the tests are also available in the book.

Minus

I found the Regular Expression chapter pretty boring and misplaced. In fact, it was the only chapter in the book where the main focus was teaching Regular Expression basics, instead of focusing on using Regular Expressions in the right way.

I would have left the RubyGems section outside the book. There have been several changes in the Gems community in the last years and the chapter appears to be slightly outdated.

A wider usage of Ruby 1.9 over Ruby 1.8 in the examples would be preferred, in order to discourage the adoption of Ruby 1.8.

Who should read it?

If you are a beginner to intermediate level Ruby programmer, this book is a must read that it's likely to help you improving your Ruby skill and writing code in the Ruby way.

If you are completely new to Ruby, I don't recommend to start with this. Approach the language by reading a "programming with Ruby" book, then read Eloquent Ruby to learn how to program in the Ruby way.

If you are a Ruby expert and you have been writing Ruby for the last 5 years, don't be too self-confident. I'm quite sure the book will be able to provide you some valuable advice.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Monday, 03 Oct 2011 09:49

Book Eloquent Ruby Eloquent Ruby (US | UK | IT) is a book about the Ruby programming language that focuses on Ruby programming style by teaching you how to write your code as a real Rubyist.

Be prepared, this is an unconventional Ruby book. To use author's words

This is a book about making that final leap, about absorbing the Ruby programming culture, about becoming truly fluent in Ruby.
A formal understanding of the mechanics of Ruby isn't the same as really looking at the programming world through Ruby-colored glasses. You need to absorb the cultural part of Ruby, to see how real Rubyist use the language to solve problems.

This is something I have been claiming for the last 5 years. Learning Ruby is not difficult, start thinking in Ruby and becoming a Rubyist is the real challenge.

Structure

The book is divided into 4 parts. Each part is divided into chapters. The book counts 31 chapters and about 400 pages.

  1. The Basics
  2. Classes, Modules, and Blocks
  3. Metaprogramming
  4. Pulling It All Together

The first part covers some basic Ruby features in a way you normally won't read in any other Ruby reference. Ah, if I only had the Symbol chapter available when I started learning Ruby!

The second part covers Classes, Modules and Blocks and it explains how to use modules successfully, how to deal with inheritance, equality and operators. This is by far my most favorite section.

The third part is about Metaprogramming. Whilst the name of the section is technically correct, it can be misleading. If you are looking for a complete Ruby and Metaprogramming course, check out Metaprogramming Ruby (US | UK). This section covers common Ruby metaprogramming topic such as hooks, method_missing (a must read!) and monkey patching.

The fourth part wraps several topics all together and talks about creating and implementing a DSL in Ruby.

The book ends with a rich list of books about Ruby and programming in general. The list contains amazing Ruby titles like Ruby Best Practices (US | UK) or The Ruby Way Second Edition (US | UK), as well programming masterpieces like The Elements of Programming Style (US | UK). If you are looking for some inspiration about your next reading, you might probably find some there.

Requirements

This book assumes that you have a basic knowledge of the Ruby language. You don't need to be a Ruby master, but some advanced sections such as Metaprogramming and DSL may require you to stop for a moment and refresh or improve your specific knowledge of Ruby on that topic.

Don't expect this book to explain you the basic details of Ruby or its syntax, this is behind the scope of this publication. There are plenty of commented examples, but if you want to learn about a specific Ruby feature make sure you keep a reference like Programming Ruby (US | UK) or The Ruby Way (US | UK) handy.

Be ready to read printed source code: this book is full or Ruby code. At least the 50% of the pages contain code, making this book a valuable practical reference.

Plus

Eloquent Ruby is a very lightweight and pleasant reading. The colloquial tone is friendly and engrossing. The books has plenty of code snippets and it requires only a few days to read it from start to end.

Aside from being an excellent resource to help you thinking Ruby and programming in the Ruby way, this book constantly adopts a practical approach providing tons of examples to read. Every chapter ends with an In the Wild section containing examples extracted from real Ruby libraries, and a Wrapping up section that helps you to fix the concepts in mind.

I appreciated the focus on tests and the RSpec chapter. The most part of the examples are verified by tests, and the tests are also available in the book.

Minus

I found the Regular Expression chapter pretty boring and misplaced. In fact, it was the only chapter in the book where the main focus was teaching Regular Expression basics, instead of focusing on using Regular Expressions in the right way.

I would have left the RubyGems section outside the book. There have been several changes in the Gems community in the last years and the chapter appears to be slightly outdated.

A wider usage of Ruby 1.9 over Ruby 1.8 in the examples would be preferred, in order to discourage the adoption of Ruby 1.8.

Who should read it?

If you are a beginner to intermediate level Ruby programmer, this book is a must read that it's likely to help you improving your Ruby skill and writing code in the Ruby way.

If you are completely new to Ruby, I don't recommend to start with this. Approach the language by reading a "programming with Ruby" book, then read Eloquent Ruby to learn how to program in the Ruby way.

If you are a Ruby expert and you have been writing Ruby for the last 5 years, don't be too self-confident. I'm quite sure the book will be able to provide you some valuable advice.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Thursday, 22 Sep 2011 15:28

Sprockets is a Ruby library for compiling and serving web assets. It features declarative dependency management for JavaScript and CSS assets and a vert powerful preprocessor pipeline that allows you to write assets in languages like CoffeeScript, Sass or SCSS.

Sprockets is now integrated in Rails 3.1 and is the core library behind the new Rails 3.1 asset pipeline. What about if you want to use Sprockets outside a Rails project?

Sprockets exposes a very powerful Rack interface to serve assets over HTTP. Integrating Sprockets in a Rack application, such as a Sinatra project, turns out to be a very straightforward task.

But in my case, I wanted to use Sprockets preprocessing and bundling feature outside an HTTP application. And it turned out Sprockets is very good at doing this as well.

I have a custom shared template I created several months ago called docss. I use this for several projects such as Ruby Whois and RoboWhois. The template is composed of several CSS files. I have a Ruby rake script that merges these files and packages them into a single asset, then compress it and publish the result to Amazon CloudFront.

Instead of processing and merging the files using file system tasks I'm now delegating this task to Sprockets. The project directory structure looks like this

├── Gemfile
├── Gemfile.lock
├── Rakefile
├── build
│   ├── javascripts
│   │   └── all.js
│   └── stylesheets
│       ├── 960.css
│       ├── alignments.css
│       ├── all.css
│       ├── reset.css
│       ├── screen.css
│       └── syntax.css
├── lib
│   └── yuicompressor-2.4.2.jar
└── src
    ├── javascripts
    │   └── all.js
    └── stylesheets
        ├── 960.css
        ├── alignments.css
        ├── all.css
        ├── reset.css
        ├── screen.css.scss
        └── syntax.css

And here's my compile task

require 'rubygems'
require 'bundler'
require 'pathname'
require 'logger'
require 'fileutils'

Bundler.require

ROOT        = Pathname(File.dirname(__FILE__))
LOGGER      = Logger.new(STDOUT)
BUNDLES     = %w( all.css all.js )
BUILD_DIR   = ROOT.join("build")
SOURCE_DIR  = ROOT.join("src")

task :compile do
  sprockets = Sprockets::Environment.new(ROOT) do |env|
    env.logger = LOGGER
  end

  sprockets.append_path(SOURCE_DIR.join('javascripts').to_s)
  sprockets.append_path(SOURCE_DIR.join('stylesheets').to_s)

  BUNDLES.each do |bundle|
    assets = sprockets.find_asset(bundle)
    prefix, basename = assets.pathname.to_s.split('/')[-2..-1]
    FileUtils.mkpath BUILD_DIR.join(prefix)

    assets.write_to(BUILD_DIR.join(prefix, basename))
    assets.to_a.each do |asset|
      # strip filename.css.foo.bar.css multiple extensions
      realname = asset.pathname.basename.to_s.split(".")[0..1].join(".")
      asset.write_to(BUILD_DIR.join(prefix, realname))
    end
  end
end

First I create a new Sprockets::Environment instance passing some configurations, such as a custom logger.

sprockets = Sprockets::Environment.new(ROOT) do |env|
  env.logger = LOGGER
end

Then I append the asset paths.

sprockets.append_path(SOURCE_DIR.join('javascripts').to_s)
sprockets.append_path(SOURCE_DIR.join('stylesheets').to_s)

Finally, I process and package the assets to the build directory.

assets.write_to(BUILD_DIR.join(prefix, basename))

Because sometimes I need to reference a single CSS file (e.g. alignments.css) instead of the entire bundle, I also build a standalone package for each CSS source. You might not want to do that.

assets.to_a.each do |asset|
  # strip filename.css.foo.bar.css multiple extensions
  realname = asset.pathname.basename.to_s.split(".")[0..1].join(".")
  asset.write_to(BUILD_DIR.join(prefix, realname))
end

Please keep in mind that if you want to use processors you must include the corresponding libraries. For example, if you want to support SASS processor you need to add the sass gem.

Here's my Gemfile.

source "http://rubygems.org"

gem 'sass'
gem 'sprockets'

That's all.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Wednesday, 07 Sep 2011 14:42

Several years ago I started keeping track of Ruby coding conventions that my team and I were using in-house. The purpose was to document the most important guidelines we employ in order to keep our libraries and source code consistent, regardless the maintainer.

The result of this effort is the Rubyist, a collection of conventions and standards for Ruby programmers. The project is now open source, you can fork it and contribute.

the Rubyist Homepage

When I first started learning Ruby, several years ago, there was a very nice project called RubyGarden. This project was a real treasure for those learning Ruby because it was full of resources and information about the Ruby world. If you have been developing in Ruby for a long time, I'm sure you'll remember it.

But most of all, the RubyGarden has been extremely helpful to me (and many others) in learning about Ruby conventions and the most notable Ruby best practices. One page in particular, the RubyStyleGuide, was a collection of Ruby coding standard and naming conventions that every Ruby developer ought to have been familiar with.

RubyGarden Ruby Style Guide

A lot has changed since then.

The RubyGarden project was shut down a few years ago. As far I remember, the wiki was invaded by spam and the www.rubygarden.org domain has now been hijacked.

The Ruby language has evolved. Ruby 1.8 and Ruby 1.9 have introduced several new syntax changes and conventions. Moreover, the adoption of the Ruby programming language has increased over the years and several new common programming patterns have arisen.

GitHub was born. If you are in the habit of reading the source code, GitHub is like a chocolate factory for a child. You can find an countless number of Ruby projects, filter them, sort them and read the source code to learn from it. Just pick some random accounts owned by notable Ruby developers, explore their programming habits and learn new exciting best practices and patterns.

Even with these newly available resources, there are many times when an quick reference can come in most handy.

Whether you are a Ruby master or a newbie, I hope you'll find the Rubyist to be a source of inspiration.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Wednesday, 07 Sep 2011 14:42

Several years ago I started keeping track of Ruby coding conventions that my team and I were using in-house. The purpose was to document the most important guidelines we employ in order to keep our libraries and source code consistent, regardless the maintainer.

The result of this effort is the Rubyist, a collection of conventions and standards for Ruby programmers. The project is now open source, you can fork it and contribute.

the Rubyist Homepage

When I first started learning Ruby, several years ago, there was a very nice project called RubyGarden. This project was a real treasure for those learning Ruby because it was full of resources and information about the Ruby world. If you have been developing in Ruby for a long time, I'm sure you'll remember it.

But most of all, the RubyGarden has been extremely helpful to me (and many others) in learning about Ruby conventions and the most notable Ruby best practices. One page in particular, the RubyStyleGuide, was a collection of Ruby coding standard and naming conventions that every Ruby developer ought to have been familiar with.

RubyGarden Ruby Style Guide

A lot has changed since then.

The RubyGarden project was shut down a few years ago. As far I remember, the wiki was invaded by spam and the www.rubygarden.org domain has now been hijacked.

The Ruby language has evolved. Ruby 1.8 and Ruby 1.9 have introduced several new syntax changes and conventions. Moreover, the adoption of the Ruby programming language has increased over the years and several new common programming patterns have arisen.

GitHub was born. If you are in the habit of reading the source code, GitHub is like a chocolate factory for a child. You can find an countless number of Ruby projects, filter them, sort them and read the source code to learn from it. Just pick some random accounts owned by notable Ruby developers, explore their programming habits and learn new exciting best practices and patterns.

Even with these newly available resources, there are many times when an quick reference can come in most handy.

Whether you are a Ruby master or a newbie, I hope you'll find the Rubyist to be a source of inspiration.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Tuesday, 06 Sep 2011 08:45

Parallels ha rilasciato oggi al pubblico Parallels Desktop 7 per Mac. La nuova major release contiene numerose novità appositamente studiate per Mac OS X Lion ed è disponibile anche in italiano.

Tra le novità più interessanti spicca la possibilità di utilizzare Launchpad e Mission Control per i programmi Windows, così come la possibilità di eseguire programmi nella nuova modalità Full Screen introdotta in Mac OS X Lion.

Inoltre, è ora possibile utilizzare le videocamere iSight e FaceTime sia in applicazioni Mac sia in applicazioni Windows.

Come facilmente immaginabile, Parallels Desktop 7 per Mac contiene anche importanti miglioramenti alle performance. Secondo parallels, l’avvio e lo spegnimento di virtual machine Windows è fino al 60% più veloce rispetto a Parallels Desktop 6, mentre la copia di file su Windows è addirittura 120% più veloce.

Gli sviluppatori apprezzeranno inoltre la possibilità di eseguire il sistema operativo OS X Lion in una virtual machine come SO guest.

OS X Lion come OS guest su Parallels Desktop 7.

Potete scaricare Parallels Desktop 7 per Mac, anche in italiano, a questo link.

Parallels Desktop 7 è in vendita a 79.99€, la licenza d’aggiornamento costa invece 49,99€. Chi ha acquistato una licenza di Parallels Desktop 6 per Mac a partire dal 1 agosto 2011 può usufruire gratuitamente dell’aggiornamento a Parallels Desktop 7.

Author: "Simone Carletti" Tags: "Software, macosx, macosx lion, parallels..."
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 11 Aug 2011 17:31

A metà luglio Apple ha rilasciato Mac OS X Lion, l’ultima versione del sistema operativo Mac OS X.

Gli attuali possessori di Parallels Desktop 6 per Mac saranno felici di sapere che le ultime build di Parallels Desktop 6 per Mac sono compatibili con Lion, sebbene il supporto per le nuove funzionalità di Lion è stato introdotto solo recentemente in Parallels Desktop 7 per Mac.

Se avete aggiornato il vostro sistema a Lion o intendete aggiornarlo, assicuratevi di utilizzare Parallels 6 Build 6.0.12094 (Revision 676494; July 13, 2011) o una versione successiva.

Parallels Desktop Build 6.0.12094

Le versioni precedenti di Parallels Desktop (versioni 4 e 5) non supportano Lion, quindi è necessario aggiornare alla versione 6 o 7 se desiderate utilizzare Parallels Desktop su Mac OS X Lion.

Potete scaricare Parallels Desktop 7 per Mac a questo link.

Author: "Simone Carletti" Tags: "Software, macosx, macosx lion, parallels..."
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 05 May 2011 10:45

This article targets Rails 3

The article was written as of Rails 3.1. The information contained in this page might not apply to different versions.

There are several ways to force your Rails application to use SSL and the HTTPS protocol.

Rails >= 3.1

If you are using Rails 3.1 (currently available in beta1) or greater, this commit makes it incredibly easy to switch from HTTP/HTTPS and vice-versa.

Simply use config.force_ssl = true in your environment configuration.

# config/application.rb
module MyApp
  class Application < Rails::Application
    config.force_ssl = true
  end
end

You can also selectively enable https depending on the current Rails environment. For example, you might want to keep HTTPS turned off on development, and enable it on staging/production.

# config/application.rb
module MyApp
  class Application < Rails::Application
    config.force_ssl = false
  end
end

# config/environments/production.rb
MyApp::Application.configure do
  config.force_ssl = true
end

Behind the scenes, Rails adds the awesome Rack::SSL Rack middleware to your application middleware stack. Rack::SSL automatically filters the request, redirects not-HTTPS requests to the corresponding HTTPS path and applies some additional improvements to make sure your HTTPS request is secure.

Rails < 3.1

If you're not using Rails 3.1 don't worry. Enabling HTTPS is as easy as adding the following line to your environment configuration.

config.middleware.insert_before ActionDispatch::Static, "Rack::SSL"

Note that I'm passing Rack::SSL as string to delegate the loading of the class at the end of the Rails application initialization. Also note the middleware must be inserted in a specific position in the stack, at least before ActionDispatch::Static and ActionDispatch::Cookies.

Don't forget to define Rack::SSL dependency in your Gemfile.

# Gemfile
gem 'rack-ssl', :require =&gt; 'rack/ssl'

Enabling HTTPS and HTTP in parallel

Transitioning an HTTP-based application to HTTPS might not be as easy as you think, especially if your application embeds assets from third-party hosts.

There are cases where you want to make your application available using both HTTP and HTTPS. For instance, we adopted this strategy in RoboDomain for a while when we moved the application to HTTPS.

Rack::SSL has a very interesting and undocumented feature. You can pass an :exclude option to determine when to enable/disable the use of HTTPS.

The following code enables Rack::SSL and all its filters only in case the request comes from a HTTPS connection.

config.middleware.insert_before ActionDispatch::Static, Rack::SSL, :exclude =&gt; proc { |env| env['HTTPS'] != 'on' }

Both the following URLs will continue to work, but the first one will trigger the Rack::SSL filters.

https://example.com
http://example.com

This solution also works very well for cloud providers like Heroku and completely replaces home-made solutions like the one I posted in this StackOverflow answer months ago, also featured here and here.

If you want to use SSL on Heroku and redirect the HTTP traffic to HTTPS, my suggestion is to go with Rack::SSL.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Thursday, 05 May 2011 10:45

This article targets Rails 3

The article was written as of Rails 3.1. The information contained in this page might not apply to different versions.

There are several ways to force your Rails application to use SSL and the HTTPS protocol.

Rails >= 3.1

If you are using Rails 3.1 (currently available in beta1) or greater, this commit makes it incredibly easy to switch from HTTP/HTTPS and vice-versa.

Simply use config.force_ssl = true in your environment configuration.

# config/application.rb
module MyApp
  class Application < Rails::Application
    config.force_ssl = true
  end
end

You can also selectively enable https depending on the current Rails environment. For example, you might want to keep HTTPS turned off on development, and enable it on staging/production.

# config/application.rb
module MyApp
  class Application < Rails::Application
    config.force_ssl = false
  end
end

# config/environments/production.rb
MyApp::Application.configure do
  config.force_ssl = true
end

Behind the scenes, Rails adds the awesome Rack::SSL Rack middleware to your application middleware stack. Rack::SSL automatically filters the request, redirects not-HTTPS requests to the corresponding HTTPS path and applies some additional improvements to make sure your HTTPS request is secure.

Rails < 3.1

If you're not using Rails 3.1 don't worry. Enabling HTTPS is as easy as adding the following line to your environment configuration.

config.middleware.insert_before ActionDispatch::Static, "Rack::SSL"

Note that I'm passing Rack::SSL as string to delegate the loading of the class at the end of the Rails application initialization. Also note the middleware must be inserted in a specific position in the stack, at least before ActionDispatch::Static and ActionDispatch::Cookies.

Don't forget to define Rack::SSL dependency in your Gemfile.

# Gemfile
gem 'rack-ssl', :require => 'rack/ssl'

Enabling HTTPS and HTTP in parallel

Transitioning an HTTP-based application to HTTPS might not be as easy as you think, especially if your application embeds assets from third-party hosts.

There are cases where you want to make your application available using both HTTP and HTTPS. For instance, we adopted this strategy in RoboDomain for a while when we moved the application to HTTPS.

Rack::SSL has a very interesting and undocumented feature. You can pass an :exclude option to determine when to enable/disable the use of HTTPS.

The following code enables Rack::SSL and all its filters only in case the request comes from a HTTPS connection.

config.middleware.insert_before ActionDispatch::Static, Rack::SSL, :exclude => proc { |env| env['HTTPS'] != 'on' }

Both the following URLs will continue to work, but the first one will trigger the Rack::SSL filters.

https://example.com
http://example.com

This solution also works very well for cloud providers like Heroku and completely replaces home-made solutions like the one I posted in this StackOverflow answer months ago, also featured here and here.

If you want to use SSL on Heroku and redirect the HTTP traffic to HTTPS, my suggestion is to go with Rack::SSL.

Author: "--"
Send by mail Print  Save  Delicious 
Next page
» You can also retrieve older items : Read
» © All content and copyrights belong to their respective authors.«
» © FeedShow - Online RSS Feeds Reader