I.T. Security and Linux Administration


September 30, 2012  2:43 PM

[Python] Processing Credit Cards Part 4 (Charging the Card)

Eric Hansen Eric Hansen Profile: Eric Hansen

Now that we can add users to our marketplace and store their credit cards for use to purchase things, lets make the magic happen!  This will be a shorter tutorial than most but still beneficial (what’s the point of processing credit cards if we don’t want money, right?).

Continued »

September 30, 2012  1:03 PM

[Python] Processing Credit Cards Part 3 (Filtering Data)

Eric Hansen Eric Hansen Profile: Eric Hansen

To continue with my series of processing cards, we covered how to add clients and credit cards last time.  This time, we’re going to cover searching Balanced for various information and filtering data.

Continued »


September 24, 2012  2:34 PM

[Python] Processing Credit Cards Part 2 (Add A Client)

Eric Hansen Eric Hansen Profile: Eric Hansen

In my previous article I wrote an introduction about Balanced Payments (BP) and why I chose them to handle credit card processing.  This time, I’m going to go over how to add a client (or buyer) to your marketplace.

Continued »


September 24, 2012  1:14 PM

[Python] Processing Credit Cards Part 1 (Intro)

Eric Hansen Eric Hansen Profile: Eric Hansen

There’s a few solutions out there for handling credit card payments without dealing with the burden of PCI compliance.  When you think about it, there’s Square, PayPal, Google Checkout, etc…  While these solutions are fine, typically they either don’t offer an API so you can integrate with them on your own level, or they don’t offer fine-grain control over how information is handled.  This is where a semi-new kid on the block comes in by the name of Balanced Payments.

Continued »


August 31, 2012  5:50 PM

Skype and Free Software Purists

Eric Hansen Eric Hansen Profile: Eric Hansen

LinuxBSDos.com recently posted an article talking about Skype and it’s usage for law enforcement.  While the article as a whole is interesting to read and adds a non-biased approach to what can be easily considered a sensitive topic (at least in the Linux community), there’s some points that should be pointed out:

Skype was never really developed for Linux.  Yes, it has had a Linux binary, even before Microsoft bought them out.  But it was so far behind the Windows client it wasn’t even worth really using if you wanted an actual VoIP client.  The only saving grace for Skype on Linux is that it was closed-source, so you couldn’t easily implement the protocol in something like Ekiga.

The term ‘free software’ is a bit of misconception in the article (and possibly the community).  To say Microsoft is not a free software company is a lie to most people, as Microsoft has released software that is, in fact, free (Microsoft Essentials is probably one of the best anti-virus programs for Windows machines).  While I know that is not the intent in making such a point, that is the first though that comes to mind.

It seems more than anything that “bashing” or nonconstructive criticizing Microsoft (and the like) is either still the cool thing to do, or people who will not let the pat go.  Back in the day, yeah, Microsoft was a thorn in the side of the open source and free software communities.  However, over the years (especially since Bill Gates stepped down) they have really changed their focus.  But why is there still all of this hate and dislike towards the company?  What does it even amount to?  Making a claim that Microsoft is the root of all evil is far from the truth, and the title should really be given to a company such as Apple (the lawsuit with Samsung really solidified that to me).

Skype and Microsoft are not the only ones to provide overly-sensitive information to law enforcement like this.  There’s not many details on the LinuxBSDos website about what it entails, but it’s really no different than countless phone carriers in the States, where they store the information for years.  While a search warrant is required to obtain such information, the carriers still comply with law enforcement on such matters.


August 31, 2012  5:14 PM

Python: Requests and fetching parts of data

Eric Hansen Eric Hansen Profile: Eric Hansen

Another Python tip for you.  In using the “Requests’ module, it allows you to iterate through content n bytes at a time.  This is quite useful when you’re dealing with large amounts of data per request (such as downloading 2GB files), as if you just call request.content it will store all the data into memory.  However, in the newest release of Requests (0.13.9 at the time of this writing), the functions iter_content() and iter_lines() (both which do about the same thing) do not work as expected out of the box.

Continued »


August 30, 2012  1:43 PM

Python: Verify SSLv2 Is Not Supported

Eric Hansen Eric Hansen Profile: Eric Hansen

There are two versions of SSL that Python can use, v2 and v3, and it just depends on what OpenSSL supports when Python is built.  The latest builds of OpenSSL remove support for SSLv2 unless you explicitly tell it to keep such a thing, but with the security risks involved in SSLv2 it’s usually never a good idea to keep it.  As such, several Linux distributions have removed the support of SSLv2 in favor of the more (but still vulnerable) SSLv3.  There are still some systems, however, that do support SSLv2 in their default binary packages, such as Arch Linux.

Continued »


August 29, 2012  10:45 AM

SSL Verification in Python

Eric Hansen Eric Hansen Profile: Eric Hansen

Python is an ever increasing popular language that is gaining a lot of ground in server management and such.  I’ve even really started using it in writing tools and scripts due to it’s shear power you have with it compared to Bash, Perl and PHP.  However, one issue I’ve had with Python, at least in the 2.x branch, is verifying that a SSL certificate is valid.

Continued »


August 8, 2012  7:25 PM

[PHP] Blesta: Support for pay-as-you-go billing

Eric Hansen Eric Hansen Profile: Eric Hansen

For the past almost 2 months now I’ve been working almost from sunrise to sunset, every day, trying to get a new service for my business up and running.  With about 95% of the entire project finished, I set out on trying to get billing to work on a non-consistent basis.

When it comes to typical billing, such as charging $200/month for a continuous service, Blesta is amazing.  It’s easy to use, manage and navigate through.  However, when it comes to creating a pay-as-you-go service, not so much.  This was further evident by the owner of the company (who also runs support) stating that while in v2 of the software (which I have) this isn’t natively possible, it is in v3.  But, he did send me in the right direction as to fixing this, even if it is more of a dirty hack than anything else.

Continued »


July 26, 2012  1:25 PM

[Python] INI Parser Script

Eric Hansen Eric Hansen Profile: Eric Hansen

So, long story short I’ve been busy working on a new service for my business.  I’ve gotten it close enough to the end now I’m happy to talk about it, and thought a blog post about one of the features would be a nice way to start things off.

I’ve been learning a lot of Python over the past week or so, and have come to appreciate it a lot more than PHP (that of which I used to adore).  It does have its faults, but all-in-all it’s a fairly powerful language that is also extremely extendable.

With that being said, my service relies on user configurations.  There’s a million ways anyone can set up a configuration file, but for the ease of use I decided to use the INI file format.  Mostly for two reasons:

  1. Easier for end-users to understand (i.e.: comments can be made in-file instead of having to read an online help document)
  2. Python has an internal parser for such files

Another option I could have done was a JSON configuration file, or even XML, but as my service will be supporting both Linux and Windows, it just seemed logical to me to use a straight-forward format.  This leads me into one of the components of my service, the configuration parser.

A link to this will be at the bottom of the page, but I’ll be going over the code as well, like usual.  This post will also be covering some points of Python for those who don’t know how to use it or know nothing about it.

from ConfigParser import SafeConfigParser
Python’s native INI file parser is called SafeConfigParser, which is derived from ConfigParser, which offers a lot of skeleton functionality for various other systems.  Instead of including ALL of the information from ConfigParser, we will only be interested in the SafeConfigParser class.
class Config:
Define’s the name of the class, so when we do “from INIConfig import Config” it will act as the same as the above from line.
def __init__(self, path=os.path.normpath(os.getcwd()), filename=”config.ini”):
__init__ is the same as “function __construct()” in PHP and likewise in C++.  It’s basically a shorthand of having to do Config.init(), so we can just do Config() instead.  To make this portable for future use, the path and filename are also possible, but have defaults of <program’s directory>/config.ini.  This is the format of my program, but you can change as you deem fit.
# Default config file: <current directory of script>/config.ini
self.file = “%s/%s” % (path, filename)
All of the “self.*” like “self.file” are variables set for the class itself, so they’re not global.  This means if I want to access the file variable somewhere else in the class, I just have to do “filename = self.file” or “return self.file”.
# Initialize the ini parser class
self.parser = SafeConfigParser()
# Read and parse the ini file
self.parser.read(self.file)
By now you can tell I comment a lot of my code, and that’s mostly because I’ll forget what it does the next day if I don’t.  This simply loads the SafeConfigParser() class and initializes it, then reads in the file the parser.
# We initially have an empty config to deal with
self.config = {}
# So we don’t initialize this every time.
val = “”
Dictionaries offer faster lookup times than other data storage, and are also easier to work with in this regard.  The ultimate idea is to be able to access sections and options by simply doing:
config = Config()
username = config['api']['username']
Where the config.ini file looks like this:
[api]
username = ehansen24
password = somerandomhashofapassword
The below code will essentially create a 2-D dictionary.  The initial key will be the section name, and then in the 2nd array the key will be the option name, followed by the value.  This is all stored in self.config, which I will show how to fetch data from in the next code block:
        # Loop through each section in the ini file
        for section in self.parser.sections():
            # Create an empty dictionary entry for each entry (otherwise: exceptions)
            self.config.update({section : dict()})
            # Loop through each option in the section
            for option in self.parser.options(section):
                # Get the value of the option (just done for clarity)
                val = self.parser.get(section, option)
                # Store the new ‘option’ : ‘option val’ dictionary entry into the section dictionary
                self.config[section].update({ option : val })
Now, as this code is pretty much commented thoroughly enough, I’ll show the entire code first, then talk about it:
    def __getitem__(self, section, option=None):
        # First we MUST have a section name given, and only continue if it’s valid
        if self.config.has_key(section):
            # If an option key was given and it exists, return the value
            if option != None and self.config[section].has_key(option):
                return self.config[section][option]
            else if option == None:
                # No option was given, user wants just the section data
                return self.config[section]
            else:
                # No option was found, even tho it was requested, return empty string
                return “”
        else:
            return {” : ”}
__getitem__ is a built-in function of Python, so when you do something such as list_array[key_name], Python is internally calling list_array.__getitem__(key_name).  So, in turn, for us to return a configuration option, for ease of use we call __getitem__.  Section itself is always mandatory, or else it’ll return an empty dictionary result.  However, if the section is provided and does exist, then we will either return the complete section, or a value of the section’s option (if the option is provided).
If you’re wondering why there’s the line “self.config[section].has_key(option)”, that’s because it’s basically short hand for this:
section = self.config[section]
section.has_key(option)
When we were storing the options and their values, the option name itself was the key, so instead of having to cycle through each entry in a for loop, we use a built in function to improve speed.  If the option was requested and it exists, provide the option (a non-dictionary result by default).  If no option was given, but the section exists, return the entire section.  Otherwise, the option doesn’t exist that was requested, so return an empty string.  Typically you’d return None instead, but for the sake of me being lazy I didn’t do it that way.
Download Link
I have the script uploaded onto my business’ GitHub at the following URL: https://github.com/SecurityForUs/PythonUtils/blob/master/config.py
My business’ website is Security For Us where I provide server and security management, PCI compliance and web hosting


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: