[PLUGIN]WebAutoType - Use URLs for AutoType with web browsers

1 2 3 > >> (Page 1 of 3)
  • AlexVallat

    AlexVallat - 2013-06-06

    This is a plugin to allow the AutoType functionality to work with browser URLs as well as window titles. It can match against the standard URL field on entries, or can have custom AutoType sequences set up to match against alternative URLs or URL patterns. Optionally, the User Name part of the sequence can be skipped when you invoke AutoType starting from a password entry box.

    It can also set a hot key for creation of new entries from the current browser page.

    Project page: http://sourceforge.net/projects/webautotype

    Download: http://sourceforge.net/projects/webautotype/files/latest/download

    Bug reports, questions and comments are welcome, as are suggestions for improvements.

    WebAutoType Options


    • Support for all major browsers: Firefox, Chrome, Internet Explorer, Opera
    • Create custom AutoType target URLs, or optionally use the standard URL field to match against
    • Create custom AutoType sequences for different URLs in the same entry
    • Automatically skip User Name part of AutoType sequence when starting in a password box
    • Optionally define a shortcut key to create a new entry, pre-populated with information from the current browser page

    This project is a continuation of CEPOPTb's original WebAutoType, made with his permission.

    • Haxus

      Haxus - 2013-06-06

      Great work Alex, and fast too! You took something that CEPOPTb did a good job on, and made it even better. The Create Entry hotkey is very helpful, and I really like the idea of skipping usernames in password boxes, although it doesn't seem to be working correctly for me. (Chrome 27.0.1453.110) Is it inspecting the HTML for the input type?

      For example, on Amazon.com my username is already in the field, so I skip to the password box and use the global autotype hotkey.

      <input id="ap_password" name="password" type="password" maxlength="1024" size="20" tabindex="2" onkeypress="displayCapsWarning(event,'ap_caps_warning', this);" class="password">

      That's the HTML for the password box, but it still types the entire sequence of {USERNAME}{TAB}{PASSWORD}{ENTER}. I'm using The WebAutoType Plugin, and I do have the option checked for "Automatically skip user name for passwords."

      Otherwise, it's serving me quite well so far, and I'm glad to be able to update to KeePass 2.22 :)

      You should see about getting this added to the KeePass plugin page for more visibility.

      Thanks you and CEPOPTb both for your hard work!

      Last edit: Haxus 2013-06-06
      • AlexVallat

        AlexVallat - 2013-06-07

        Thanks for the comments!

        Chrome, by default, does not expose the accessibility information for the web page itself, so while we can still get the URL, we can't get anything else.

        To enable accessibility from Chrome, start it with thes flag: --force-renderer-accessibility

        Or, visit this url to turn it on from within Chrome: chrome://accessibility

        Once it's turned on, the advanced features of WebAutoType should just start working.


        • Haxus

          Haxus - 2013-06-07

          Today I learned...


          Thanks Alex.

  • Dominik Reichl

    Dominik Reichl - 2013-06-08

    Wonderful, thanks a lot!

    I've updated the WebAutoType listing on the KeePass plugins page:

    Best regards,

    • AlexVallat

      AlexVallat - 2013-06-08

      That's great, thank you. I'm pleased to be able to use KeePass without needing a browser extension, and will maintain this plugin to continue to do so.


  • RandyHa11

    RandyHa11 - 2013-06-08

    Great job -- love it! I have a handful of sites which set the window title to something generic like "Login", so whenever I try to Auto-Type it makes me choose which of those I want. Now I can match them against a URL and Auto-Type will know which one to use without needing to prompt me. Very cool. Thanks for sharing!

  • AlexVallat

    AlexVallat - 2013-08-22

    Chrome v29 made some changes which broke compatibility when accessibility is not turned on.

    If you're using Chrome and noticed WebAutoType stopped working, then please update to v3.2 from the usual download link: http://sourceforge.net/projects/webautotype/files/latest/download

    3.2 also improves the reliability of UIA field detection after a focus shift (such as after entering the master password), at the cost of introducing a maximum 1 second delay if the field with the focus when you trigger AutoType isn't an edit or password field of some sort (not just in a web browser, anywhere). This should rarely be the case, but if you experience it to be a detrimental change then let me know and I can take steps to improve it, or at worst, make it optional.

    • Haxus

      Haxus - 2013-08-22

      I was having some issues with a few websites, but everything is working great again. The 1 second delay is worth it if it helps with compatibility. Thanks Alex. :)

  • AlexVallat

    AlexVallat - 2013-10-16

    WebAutoType 3.3 is now available from the usual download link: https://sourceforge.net/projects/webautotype/files/latest/download

    This is (again) for improving Chrome compatibility - this version should work with non-English versions of Chrome v29 and newer too.

    I've also added a new optional function. In the options window, there is now a checkbox for "Show search for repeated autotype". If checked, this works such that if you hit your global auto type hotkey, but no match is found, then you can just repeat the hotkey and KeePass will show the search window, pre-populated with the URL of the page you are on, in case what you want to search for is part of that.

    This can be helpful for when you are sure you have an entry for the page, but for some reason it just isn't matching the autotype (usual culprits for me are http vs. https, having forgotten to put the URL in at all, autotype disabled for the entry or group in question, or different TLD (.com, .co.uk, etc.)).

  • John

    John - 2013-10-18

    If you set up AutoType to type {HOME}+{END}{Username}{TAB}{HOME}+{END}{Password} then KeePass always clears the field before sending keystrokes. So, even if a Username field is pre-completed, you can still click in Username as KP will clear it before sending the Username.
    As a consequence, you ALWAYS place the mouse in Username before pressing ctrl/alt/a.

  • John

    John - 2013-10-18

    Is there a way in which you could parse the web address so as to guarantee that the user was on the genuine web site, and not a spoof site?

    For example, Lloyds bank in the UK starts out at http://www.lloydsbank.com/.

    If you click on Logon, you get taken to the secure site https://online.lloydsbank.co.uk/personal/logon/login.jsp, where "lloydsbank.co.uk" cannot be spoofed (and is highlighted bold in Firefox address bar).

    If you submit a correct ID and password you are taken to a secure site https://secure.lloydsbank.co.uk/personal/blah_blah_blah_etc, where the "secure" prefix is different from the previous "login" prefix.

    If the user could be assured that he was at the real Lloyds bank site, and not a spoof site like lloydsbank.co.uk/nasty_person.com/, it would give added security.

    • AlexVallat

      AlexVallat - 2013-10-18

      Sorry, but I'm really not clear on what it is you are requesting here - it's possible that this is already the way it behaves, though.

      If I set up an entry with the URL https://online.lloydsbank.co.uk/ then it won't match against https://online.lloydsbank.co.uk.nasty_person.com/ (presumably that's what you meant - as /nasty_person.com would imply that the URL was a page served under the real lloydsbank.co.uk domain).

      If you need finer control over the matching URLs then you can use the Auto-Type tab of the edit entry window. Click the Add button and then in the Edit Auto-Type Item window click the URL button. You can then put the URL that you want to match into the box. Bear in mind that this must be an exact match, so if you want wildcard behaviour, you have to actually end it with a *.

      For example, if you wanted the URL field to be http://www.lloydsbank.com/, but did not want autotype to be performed on sites starting with http://www.lloydsbank.com/ and only want it on the specific URL https://online.lloydsbank.co.uk/personal/logon/login.jsp then what you can do is go to the Auto-Type tab of the entry, override the default sequence to be blank, then add a custom sequence (not using default) for the https://online.lloydsbank.co.uk/personal/logon/login.jsp URL (it will appear in the list with a "??:URL:" prefix in the target window column, ignore that, it's just so that it knows it's supposed to be a URL and not a window title).

      That way it would only ever auto-type into the page with that exact URL.


      Last edit: AlexVallat 2013-10-18
  • TimK

    TimK - 2013-11-02

    First of all thank you very much for this useful plugin. I prefer it to using the default window title match in KeePass.

    I do have a performance problem though: I have about 700 entries in KeePass and some of them have 2-5 URLs added, sometimes with wildcards. At times the auto-type feels slow compared to the built-in KeePass window title way, there's a ~2 sec. delay before it starts auto-typing. Is this related to the accessibility way of getting the URL from the browser or rather to the matching of URLs, as it probably has to go through all entries each time. Is there anything I can do to speed it up?

  • AlexVallat

    AlexVallat - 2013-11-03

    Hello TimK, I think the first thing to do is to pin down where the problem is.

    Firstly, can you try creating a new test database, and just put one card in it? If the delay is due the number of cards, then auto-typing from the test database would be fast.

    If it is still too slow even with the small test database, then the delay can't be the number of cards, so try adding two entries with the same URL, and then auto-typing again. This will let you see if the delay is in obtaining the URL from the browser (in which case it will occur before showing the selector window to pick the entry to auto-type) or in the auto-typing itself (in which case there will be a delay after you pick an entry to auto-type).

    Finally, if the delay is determined to be in obtaining the URL, then please can you let me know which browser and version you are using? Getting the URL is necessarily slower than just getting the window title, as it has to go through accessibility interfaces, but it shouldn't be as much as 2 seconds.


  • TimK

    TimK - 2013-11-04

    Alex - thank you very much for your prompt reply.
    I tried exactly what you suggested above and here's my conclusion: it is slow to get the URL from the browser (Firefox). When there are 2 identical entries, it takes a bit of time to pop up the selection dialog, then once I select an entry the actual typing goes quickly.
    Here's my setup and some observations:
    - Firefox 25.0 running on Win7 Pro x64. I tried it on Chrome and IE and while there is some delay with those browsers too, it's not as bad as Firefox. I noticed Chrome is the fastest one to get to the selection dialog, then IE, then Chrome. These are with all the latest stable versions of these browsers as of today, all other OS updates applied. I'm just running MSE, no other security software that monitor various calls or interactions between apps and windows.
    - The slower the computer is (I tried it on some underpowered laptop) the slower it is to get to the selection dialog. On a slow laptop it takes 4 sec. to get to the selection dialog.
    - Unchecking "Use the URL field value for matching" is not enough to speed it up. I have to remove the WebAutoType plugin completely and then KeePass auto-type is almost instantaneous.

    Any ideas?

  • AlexVallat

    AlexVallat - 2013-11-05

    Hi Tim,

    Thanks for getting back to me. Did you try the test with a smaller test database? I wasn't sure from your reply if you did.

    In any case, there's another test that will give some more clues: if you go to WebAutoType Options and set a hot key for Create Entry from Web Page, then we can test the reading of the window information without performing the entry search.

    Once you've got the hotkey set, go to Firefox and type some text into a textbox on a web page (like a Username field for log-on). With the cursor in that textbox, hit the new hotkey. KeePass should create a new entry, and populate it with the title of the page, the URL of the page, and the text of the textbox as the username. Could you let me know if it gets all three pieces of information, and if the delay is the same in bringing up the new entry?

    Sorry about all this, but if I can't figure out exactly where the delay is, I won't know which bit needs fixing! On my machine, it's all instant...


  • TimK

    TimK - 2013-11-05

    Alex - yes, my original test was with a fresh database with just 2 similar entries in it, nothing else.

    I tried your "save entry" test. It does capture all the info correctly, but it is slow to pop up the KeePass window that asks to save the card. So it seems capturing the info from Firefox is slow.

    I even tried a clean Firefox profile just in case any of my addons are at fault. It still slow, maybe it feels just ever so slightly faster than my regular profile or it might be just my imagination because the profile is "clean".

    I will continue helping you investigate, if you need any other tests, please let me know. Meanwhile, do you think it is a good idea to remove WebAutoType and instead use a browser addon that always adds the full hostname to the window title so that I can do more reliable matching based on the KP built-in window title approach?

    Last edit: TimK 2013-11-05
  • TimK

    TimK - 2013-11-06

    Alex - one more issue with Chrome this time: I like to set the match URLs to always end with / for added security, e.g. https://example.com/ rather than simply https://example.com IE and Firefox seem to return the trailing / but Chrome does not. Is it possible for WebAutoType to always make it a rule for the simple URLs that have no path to enforce that the match is done using a trailing slash?
    I don't want to have a match rule https://example.com* as that could possibly match something malicious such as https://example.com.hacker.com

  • AlexVallat

    AlexVallat - 2013-11-06

    Tim, thank you for the additional information. The fact that the Create Entry test captures all the information correctly does indicate that although UIA access is working (not timing out, for example), it is just working very slowly. That pins down the area of the problem quite precisely, unfortunately it's also something that I don't think I can fix. Unlike the Search case, the Create Entry case doesn't do any waiting, retrying or anything else under my control, it simply asks for UIA information in the most direct way possible.

    I will do some research and see if I can discover any specific circumstances under which UIA might run slowly, but I'm not optimistic. If you are happy with using the browser add-on, that's up to you - I can certainly understand how a 4 second delay would be irritating enough to look for alternatives.

    To answer your second question, I'm not sure that WebAutoType should be adding slashes, it's the sort of thing that's easy to get wrong in strange edge cases (and if there's one thing URLs have in abundance, it's strange edge cases). On the other hand, I do see where you're coming from, and having to set up an exact-match using a custom auto-type match for the entry would be a pain. I'll consider it for the next release.


  • TimK

    TimK - 2013-11-06

    Thank you Alex. Please play with URLs like https://example.com vs. https://example.com/ in Chrome, the problem will be obvious and annoying quickly :-)

    It's strange that UIA depends on the machine. On an i7 quad-core it seems to be decent, but on slower i3 laptops the problem is evident.

  • TimK

    TimK - 2013-11-07

    Alex - is there a way to contact you via email? I'm wondering if you could put together a very simple standalone test app that tries to read the URL and perhaps other info from the browser via UIA and logs the info and how long it took to get it. Or maybe WebAutoType already has such a debug mode.
    I'd be curious to run it on a few machines and collect data across machines and across browsers. What do you think?

  • TimK

    TimK - 2013-11-08

    Alex has been very helpful putting together a quick test. A big THANK YOU, you are a great developer!
    Unfortunately it seems that grabbing the URL from the browsers via UIA is very slow on my machines, in one case over 3 sec. to get it from Firefox. We have no ideas what could be causing it and how it could be fixed.
    Anyone else noticing any performance issues with WebAutoType?

  • Horst

    Horst - 2013-11-09

    No problems here.
    I tested it under Windows 7 x64
    using IE 11, Firefox 25 and Chrome 30.0.1599.101
    IE and Firefox are very fast, Chrome is a litte bit slower but still fast enough.
    I have about 130 entries in my Keepass database (version 2.24)

    Last edit: Horst 2013-11-09
  • TimK

    TimK - 2013-11-11

    I tried doing just addons to copy the URL to the window title and not use WebAutoType. Unfortunately the solution works well with Firefox only, but not with Chrome or IE. The problem is for Chrome or IE the addons simply run some javascript to change the page title. That is not reliable if the page itself uses javascript to change the page title, many times the URL does not show up in the page title. Only Firefox seems to implement it reliably because I think it just changes the window title natively.
    It seems that right now if I want to use URLs reliably WebAutoType is the answer, but in my case it adds some significant delay. I will just have to live with it until some better browser integration comes along (I tried KeeFox, PassIFox and the likes but coming from Roboform they all seem like they need improvement).

  • TimK

    TimK - 2013-11-23

    Did anyone else notice that Chrome has global accessibility mode turned ON by default on Windows 8 but it is OFF by default on Windows 7. Anyone know why and if there's a way to have it ON on Windows 7 all the time without starting it with a command line flag or enabling it via chrome://accessibility each time?

  • AlexVallat

    AlexVallat - 2013-11-24

    Huh, I had not noticed that that chrome://accessibility setting was not persisted if you restart Chrome (I'm a Firefox user, personally). That's irritating. I'll investigate how screen readers interact with Chrome, I find it hard to believe that they would require the unfortunate blind user to manually set this setting every time they want to use Chrome.

  • Horst

    Horst - 2013-11-24

    I have the problem on starting Keepass 2.24 in Windows 8.1 (Preview)
    It fails to compile the plugin (actual version) with the following error:

    "Der Vorgang ist aufgrund des aktuellen Zustands des Objekts ungültig."
    English translation: Operation is not valid due to the current state of the object.

    • David Lechner

      David Lechner - 2013-11-24

      Horst, Run KeePass from a command line using the --saveplgxcr option. If you don't know what I am talking about, just ask and I will explain better.

      Doing this will save the plugin compile results to a temporary file. Attach that file here so that we can see what the error is.

      • Horst

        Horst - 2013-11-25

        Thanks, that helped.
        I found that UIAutomationClient.dll was missing.
        After enabling the old .NET 3.5 features in Windows 8.1 Preview
        the plugin compilation was successfull.

  • TimK

    TimK - 2013-11-24

    I have the problem on starting Keepass 2.24 in Windows 8.1 (Preview)
    It fails to compile the plugin (actual version) with the following error:

    It works for me on Win 8.1 upgraded from the app store. It may help to shut down KeePass, clean up the plugin cache and start KP again. The plugin cache is usually in: C:\Users\username\AppData\Local\KeePass\PluginCache

  • TimK

    TimK - 2013-11-24

    Huh, I had not noticed that that chrome://accessibility setting was not persisted if you restart Chrome (I'm a Firefox user, personally). That's irritating. I'll investigate how screen readers interact with Chrome, I find it hard to believe that they would require the unfortunate blind user to manually set this setting every time they want to use Chrome.

    Yes very strange and I wonder too what the blind user is supposed to do. Strange that it's OFF by default on Win7 and not sticky, but it's ON by default on Win8 and sticky. Chrome is nice and fast but at times frustrating.

    We talked about another issue on the previous page: Chrome returns a URL without the trailing slash, e.g. http://example.com if accessibility mode is OFF, but it returns it with the trailing slash e.g. https://example.com/ if accessibility is ON. This messes with the pattern matching for URLs. I define all URLs to match against the version with the trailing slash, for security. Matching against something like https://example.com* looks insecure to me, some rogue site could have a subdomain such as https://example.com.roguesite.net and don't want to submit my password there by accident.

  • AlexVallat

    AlexVallat - 2013-11-24

    Horst: I'm afraid I don't have enough information to guess why it might be failing to compile for you. Have you tried any other .plgx plugins on the same system? Is there any more detailed error message, or is that the only thing the message says?

    TimK: I've found some information on how Chrome probes for the presence of a screen reader, so I've made some changes to WebAutoType to respond to those probes. I've uploaded version 3.4 which, with any luck, will make Chrome automatically use accessibility without any need for user configuration.

    For your trailing slash, I would suggest that in most cases you should match the full url, so https://example.com/login.html, to avoid accidentally auto-completing your password into a comment box or similar. In any case, the issue, at least for Chrome, should now be moot as accessibility will always be enabled, and therefore the url will always be returned with a trailing slash!

    WebAutoType 3.4 is now available from the usual download link: https://sourceforge.net/projects/webautotype/files/latest/download

  • TimK

    TimK - 2013-11-24

    For your trailing slash, I would suggest that in most cases you should match the full url, so https://example.com/login.html, to avoid accidentally auto-completing your password into a comment box or similar. In any case, the issue, at least for Chrome, should now be moot as accessibility will always be enabled, and therefore the url will always be returned with a trailing slash!

    Ideally yes, I agree with you. But many times that is not possible. For example a few banks have the login form straight on their main page. In general I'm not worried about passwords for forums and other non-important sites, those can leak. It's the important sites I'm worried about and it's unfortunate that they choose to have the login form on the main page which many times is not even HTTPS, even though the actual form does submit to a HTTPS URL. Very poor practice in my opinion.

    I'll give 3.4 a try and report back. Any chance you could fix the check for updates in KP so that it can check for the latest version of the plugin? Thanks!

    Last edit: TimK 2013-11-24
  • TimK

    TimK - 2013-11-25

    Just want to say THANK YOU for fixing the accessibility problem in Chrome. It seems to work well now, though Chrome 31 has a bug where Global accessibilit mode is still shown as off but it's actually on. Apparently fixed in Chrome 32:

  • Haxus

    Haxus - 2014-01-03

    I no longer have a delay in Chrome since upgrading from 3.3 to 3.4. This version is working great!

    One minor thing I've noticed is that when I use the option for skipping the username when in a password field, it pops up with an auto-type entry selection screen where I need to pick either the {USERNAME}{TAB}{PASSWORD}{ENTER} option or the {PASSWORD}{ENTER} option. I have the option for using the URL field value for matching turned off.

    Really not a big deal though. I only have one site that I ever need that for, and it's easy enough to just clear out the username field to let it type the normal sequence.

  • AlexVallat

    AlexVallat - 2014-01-04

    With the Skip Username option turned on, WebAutoType only skips the Username for entry sequences that are found using WebAutoType - it doesn't affect sequences that are matched by other means (like Window Title, for example), or explicitly defined overriding custom sequences.

    From your description, I suspect that's what's happening is that your entry matches both a ??URL: target (with Default custom sequence), and also matches by Title or some other standard Keepass mechanism. So WebAutoType will modify the URL one to skip the username, but can't affect the standard one.

    Other than just living with it, you have two options. You can go to Keepass Options, Advanced, and uncheck all the "An entry matches if..." options under Auto-Type (custom sequences should still work). Or, you can edit the entry in question to not match except by the URL target.


  • garyp

    garyp - 2014-01-18

    I've just installed WebAutoType and noticed the same Firefox delay problems that were reported by TimK here. After some investigation I've found that the delay is cause by Comodo Firewall, in particular the Defense+ component. I thought I should post what I've found in case it helps someone else.

    Disabling Defense+ completely removed the delay for me but I wasn't particularly happy with this solution. I little bit of research found this page http://www.techsupportalert.com/content/how-tame-comodo-defense-without-disabling-it.htm which although isn't written specifically for my version of Comodo (5.12) mentions purging unused/dead entries in Defense+.

    What I did was to perform the following actions:
    Defense+ > Computer Security Policy > Defense+ Rules > Purge
    Defense+ > Computer Security Policy > Protected Files and Folders > Purge

    This has reduced the delay from about 3 seconds to a slight delay. The delay can be improved again if 'Protected COM Interfaces' is unchecked in Defense+ Settings > Monitoring Settings but I've chosen not to do this.

    Hope this helps or gives some clues to others with the same problem.


    Last edit: garyp 2014-01-18
  • TimK

    TimK - 2014-02-03

    Thanks @garyp for the info. Interesting info about Comodo. I do have Comodo 5.12 installed on one of the machines (Win7 Pro x64) but I keep Defense+ disabled. The slowness also happens on a Win 8.1 Pro x64 machine that does not have Comodo installed. There must be some other interactions.

  • Sebastian

    Sebastian - 2014-04-10


    if i check for Updates off KeePass, it checks also Updates for my installed Plugins. Only WebAutoType Plugin 3.4 could not be checked, since there seems to be no Versiopn Information comes back from the Online Source. Is it possible to add a check also for this Plugin?

  • rasenplanscher

    rasenplanscher - 2014-06-13

    First off: Thank you for the plugin, it's a huge help!

    Now for the one thing that's bugging me right now: I currently use the Pale Moon browser, which is based on Firefox 24 ESR, and unfortunately the WebAutoType plugin does not seem to work with it. Is there something I can do to make this work? Otherwise, do you happen to know the nature of the problem and can explain it?

  • AlexVallat

    AlexVallat - 2014-06-13

    Posting in the WebAutoType forum is always a good idea (as I get notified of posts there), but I do occasionally look in on this forum too.

    To answer your question, Pale Moon deliberately removed accessibility features for performance reasons(ref), so the URL can not be read by WebAutoType. I don't know how much of an impact accessibility has on performance, but as Pale Moon doesn't seem to offer any configuration option to turn it back on again, you might be out of luck, sorry.


    • rasenplanscher

      rasenplanscher - 2014-06-19

      What a pity. Still, thanks a bunch =)

  • AlexVallat

    AlexVallat - 2014-06-23
    WebAutoType v3.5 Released

    Google have fixed(ish) the Accessibility detection again in newer versions of Chrome. It only works if KeePass is running before Chrome is run, so not ideal, but better than nothing. To celebrate, I've patched up WebAutoType to fix the advanced functionality (such as automatic password-only autotyping) with Chrome when Accessibility is turned on. (If you don't want to have to have KeePass running before Chrome starts, you can still use the --force-renderer-accessibility command line flag)

    I've also added optional support for the KeePass "Check For Update" functionality, using the SourceForge Update Checker helper plugin.

    Last edit: AlexVallat 2014-06-23
  • Horst

    Horst - 2014-06-23

    It looks like this version breaks the Check for updates feature.
    It never comes to an end.
    The SourceForge Update Checker is installed and the checks worked with the previous version.
    KeePass itself is at version 2.26

    • AlexVallat

      AlexVallat - 2014-06-23

      Hmm, that's a weird one. I can reproduce it, but only when I don't have a web debugger running! Must be something to do with proxies.

      Anyway, I think I have a fix for it, could you try downloading the v0.2 of the SourceForge Update Checker which should hopefully resolve the issue.

1 2 3 > >> (Page 1 of 3)

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks