Sebastian Thomschke

IT Consultant – Java, J2EE, IBM WebSphere Portal, Lotus Notes/Domino
RSS icon Home icon
  • getpass for Jython

    1 Star2 Stars3 Stars4 Stars5 Stars
    Loading...
    Posted on 21 November 2008 Sebastian Thomschke*/?> 1 comment

    In my current project I am developing some Jython based command line tools and had the need for masking passwords entered in the command shell. Python provides the getpass module for this purpose. Unfortunately this module has not been made available for Jython.

    Here comes a module I wrote to provide this kind of functionality. It uses the mechanism described here http://java.sun.com/developer/technicalArticles/Security/pwordmask/ to mask characters entered at the command prompt. Additionally if Java 6 or higher is running Jython the module will instead use the new Console.readPassword() method. In case the module is running in an environment where the getpass module is available it will delegate to the corresponding methods of this module instead of using its own implementations.

    # ext_getpass.py
    # @author Sebastian Thomschke, http://sebthom.de/
    import thread, sys, time, os
    
    # exposed methods:
    __all__ = ["getpass","getuser"]
    
    def __doMasking(stream):
        __doMasking.stop = 0
        while not __doMasking.stop:
            stream.write("b*")
            stream.flush()
            time.sleep(0.01)
    
    def generic_getpass(prompt="Password: ", stream=None):
        if not stream:
            stream = sys.stderr
        prompt = str(prompt)
        if prompt:
            stream.write(prompt)
            stream.flush()
        thread.start_new_thread(__doMasking, (stream,))
        password = raw_input()
        __doMasking.stop = 1
        return password
    
    def generic_getuser():
        for name in ('LOGNAME', 'USER', 'LNAME', 'USERNAME'):
            usr = os.environ.get(name)
            if usr: return usr
    
    def java6_getpass(prompt="Password: ", stream=None):
        if not stream:
            stream = sys.stderr
        prompt = str(prompt)
        if prompt:
            stream.write(prompt)
            stream.flush()
    
        from java.lang import System
        console = System.console()
        if console == None:
    	    return generic_getpass(prompt, stream)
        else:
            return "".join(console.readPassword())
    
    try:
        # trying to use Python's getpass implementation
        import getpass
        getpass = getpass.getpass
        getuser = getpass.getuser
    except:
        getuser = generic_getuser
    	
        # trying to use Java 6's Console.readPassword() implementation
        try:
            from java.io import Console
            getpass = java6_getpass
        except ImportError, e:
            # use the generic getpass implementation
            getpass = generic_getpass
    

    Here is an usage example:

    import ext_getpass as getpass
    
    pw = getpass.getpass("Please enter your password:")
    print "The entered password was: " + pw
    
  • WebSphere Portal 6.1.0.0 does not support installation on a managed node

    1 Star2 Stars3 Stars4 Stars5 Stars
    Loading...
    Posted on 19 September 2008 Sebastian Thomschke*/?> No comments

    With WebSphere Portal 5.1 a new deployment option was introduced that allowed the installation of WP onto an existing node managed by a deployment manager. AFAIK the main reason for this new option was to simplify the cluster setup procedure.

    Both options, installing WP standalone and federating it into a cell afterwards as well as installing it on an already managed node have different pros and cons each. In WP 6.0 the installation onto a managed node was even mandatory to enable WebSphere Process Server integration.

    Surprisingly WP6.1.0.0 does not support the installation on a managed node anymore. All nodes of a cluster need to be installed as standalone systems first and then be federated into a WebSphere cell.

    For WP 6.0 the installation procedure is described here. The 6.1 info center does not mention this procedure anymore and it no, it was not dropped accidentally.

  • [Solved] Blank Pages with WordPress 2.6.x

    1 Star2 Stars3 Stars4 Stars5 Stars
    Loading...
    Posted on 13 September 2008 Sebastian Thomschke*/?> 2 comments

    After upgrading to WordPress 2.6 it occasionally happend that an empty page was displayed in the browser when navigating through the blog or working in the admin area. Refreshing the browser using CTRL+F5 usually helped in that case. Today I upgraded to WordPress 2.6.2 and I was not able to access the plug-ins page of the admin area anymore. No matter how often I refreshed the page in the browser it stayed blank.
    First I searched the web for possible solutions. I found quite a number of discussions giving tips about this widely known problem but unfortunately none of these solutions helped in my case.
    So I again started debugging the WordPress code and finally found the lines of code causing the trouble. The problem are (object) casts in the wp-includes/taxonomy.php file that transform an array into an object:

    $wp_taxonomies['category'] = (object) array('name' => 'category', 'object_type' => 'post', 'hierarchical' => true, 'update_count_callback' => '_update_post_term_count');
    $wp_taxonomies['post_tag'] = (object) array('name' => 'post_tag', 'object_type' => 'post', 'hierarchical' => false, 'update_count_callback' => '_update_post_term_count');
    $wp_taxonomies['link_category'] = (object) array('name' => 'link_category', 'object_type' => 'link', 'hierarchical' => false);
    

    Since I don’t get any error messages neither on the screen nor in the log files I have no idea why these casts fail. The PHP version used to serve the site is the latest stable 5.x release from php.net.
    As a workaround I introduced a function that does also transforms an array into an object but does not rely on the casting mechanism.

    function arr2obj($arr) {
    	foreach ($arr as $k => $v) $obj -> {$k} = $v;
    	return $obj;
    }
    
    $wp_taxonomies['category'] = arr2obj(array('name' => 'category', 'object_type' => 'post', 'hierarchical' => true, 'update_count_callback' => '_update_post_term_count'));
    $wp_taxonomies['post_tag'] = arr2obj(array('name' => 'post_tag', 'object_type' => 'post', 'hierarchical' => false, 'update_count_callback' => '_update_post_term_count'));
    $wp_taxonomies['link_category'] = arr2obj(array('name' => 'link_category', 'object_type' => 'link', 'hierarchical' => false));
    
  • Sun JDK5/6 compilers broken when linking overloaded methods with variable arguments

    (5 votes) 1 Star2 Stars3 Stars4 Stars5 Stars
    Loading...
    Posted on 16 May 2008 Sebastian Thomschke*/?> 1 comment

    We are currently switching the build system of OVal from custom Ant scripts to Maven 2. During that process we accidentally compiled the project using the Java compiler of the Sun JDK 5 instead of the AspectJ compiler. Surprisingly javac did not complain about the missing aspect class files. Instead it already aborted while compiling an ordinary Java class which only referenced other non-AspectJ related classes. This is the original error message:

    [INFO] [compiler:compile]
    [INFO] Compiling 180 source files to C:\projects\oval\src\trunk\target\classes
    [INFO] ------------------------------------------------------------------------
    [ERROR] BUILD FAILURE
    [INFO] ------------------------------------------------------------------------
    [INFO] Compilation failure
    C:\projects\oval\src\trunk\src\main\java\net\sf\oval\Validator.java:[373,58] 
    addMethodParameterChecks(java.lang.reflect.Method,int,java.lang.Object)
    has private access in net.sf.oval.internal.ClassChecks 

    There exist multiple methods named addMethodParameterChecks in the class ClassChecks with different signatures. The problem is that javac tries to link against the wrong method when compiling the class calling one of the methods.

    Read the rest of this entry »

  • Making the DD Sitemap Generator Plug-in work with multilingual blogs

    (2 votes) 1 Star2 Stars3 Stars4 Stars5 Stars
    Loading...
    Posted on 1 May 2008 Sebastian Thomschke*/?> 3 comments

    To create a bilingual blog with WordPress I am using the Language Switcher Plug-in. This plug-in allows you to put content in more than one language into the post title and content fields by surrounding the localized texts with special tags indicating their language (e.g. “[ lang_en]Hello World[ /lang_en][ lang_de]Hallo Welt[ /lang_de]”). When the posts are viewed in the browser the plug-in will determine the active language and strip off the texts specified in all other languages on the fly.

    I am using the great DD Sitemap Generator Plug-in for WordPress to automatically render a site map based on the posts, pages and categories created in my blog. The problem however is that the generated site map is not language aware and displays the page/post titles and category names including the tags and the texts of all languages at once.

    To solve this I started digging a bit into the code of WordPress and the Language Switcher Plug-in. The Language Switcher Plug-in achieves the on-the-fly processing of multilingual texts by hooking itself into the so called Filters API which is something like an event-based callback mechanism. Plug-ins can signal their interest in a certain text filter event by calling the add_filter(the_event_id, the_name_of_a_function_to_callback) function provided by the WordPress API to register one if it’s functions that will be invoked by WordPress when the filter event occurs. Besides registering for filter events, plug-ins can also fire such events by calling the apply_filters(the_event_id, the_text_to_be_filtered). WordPress will then apply all registered filters to the text passed over and the apply_filters will return a “filtered” version of the passed text. When rendering the title of a post or page WordPress fires the filter event “the_title” allowing plug-ins to process/modify the title before it is actually displayed. Therefore the Language Switcher Plug-in registers itself to this event and a lot of others to be able to strip off the language tags and the texts in languages other than the currently active one.

    Unfortunately the DD Sitemap Generator Plug-in is currently not applying the respective filters when rendering the site map. Therefore the Language Switcher Plug-in is not aware of it and as a result the site map shows all translations of a category name or page/post title at the same time no matter which language is currently active.

    To solve this problem I analyzed the source code of the DD Sitemap Generator Plug-in and added the missing apply_filters calls where appropriate. You can follow these steps in case you are having the same issue:

    1. Open the file <wordpress_root>/wp-content/plugins/sitemap-generator/sitemap-generator.php (or <wordpress_root>/wp-content/plugins/dd-sitemap-gen/dd-sitemap-gen.php) in an editor
    2. Locate the text
         $tmp_array[‘title’] = $pages[$k]->post_title;
      and replace it with
         $tmp_array[‘title’] = apply_filters(‘the_title’, $pages[$k]->post_title);
    3. Locate the text
         $tmp_array[‘title’] = $cat_data[$c][‘cat_name’];
      and replace it with
         $tmp_array[‘title’] = apply_filters(‘the_category’, $cat_data[$c][‘cat_name’]);
    4. Locate the text
         $tmp_array[‘title’] = $posts[$k]->post_title;
      and replace it with
         $tmp_array[‘title’] = apply_filters(‘the_title’, $posts[$k]->post_title);
    5. Save the file and you are done.

    If you are encountering similar problems with other plug-in you can use the same approach to make them play nicely with the Language Switcher Plug-in.

  • [Solved] WordPress 2.5 One-Click Plug-in Upgrades – Could not create directory

    (6 votes) 1 Star2 Stars3 Stars4 Stars5 Stars
    Loading...
    Posted on 25 April 2008 Sebastian Thomschke*/?> 42 comments

    Some days ago I upgraded my WordPress installation to the new 2.5 release. Being a lazy guy I of course wanted to use the new one-click plug-in upgrade feature to update several plug-ins. Trying to one-click update some of the out-dated plug-ins only resulted in the rather meaningless error message “Could not create directory”. So I started searching the web for possible solutions. I quickly found some posts explaining this issue to be a directory permission problem. Manually creating the /wp-content/upgrade directory and chmoding it as well as the plug-in directories to 777 should solve the problem. Unfortunately not for me. Therefore I rolled up my sleeves and started to debug WordPress…

    To cut a long story short, eventually I came across this PHP bug report #42739 mkdir doesn’t like a trailing slash when safe_mode is enabled and it turned out that this was the issue I was facing with on my hosting account too. The safe_mode option is enabled and WordPress tries to create directories that end with a slash (e.g. /htdocs/wp-content/upgrade/the-plugin/).

    After knowing the reason I could develop a workaround and finally got the one-click updater running. If you are facing the same issue you can try to use my patch too.

    1. Locate and open the file <wp_root>/wp_admin/includes/class-wp-filesystem-direct.php in an editor
    2. Search for “function mkdir
    3. Add the following statements to this method
      function mkdir($path,$chmod=false,$chown=false,$chgrp=false){
      	if( ! $chmod)
      		$chmod = $this->permission;
      
      	// workaround for http://bugs.php.net/bug.php?id=42739 starts here
      	if(ini_get('safe_mode') && substr($path, -1) == '/')
      	{
      		$path = substr($path, 0, -1);
      	}
      	// workaround for http://bugs.php.net/bug.php?id=42739 ends here
      
      	if( !@mkdir($path,$chmod) )
      		return false;
      	if( $chown )
      		$this->chown($path,$chown);
      	if( $chgrp )
      		$this->chgrp($path,$chgrp);
      	return true;
      }
    4. Start one-click updating!

    Update 1:

    1. The patch also works for WordPress 2.5.1
    2. If applying this patch does not lead to success the problem may have a second cause. Therefore also check the permissions on the /wp-content/upgrade/ folder and it’s sub folders, e.g. chmod them to 777. If the upgrade directory does not exist at all it may be sufficient to create it manually.

    Update 2:

    1. In case the patch does not work check if you have the AskApache Password Protect plug-in installed.
    2. If so, try to deactivate this plug-in before you try to upgrade any other plug-in.