Resetting Continuum passwords

26 01 2007

The only place I could find info on resetting a Continuum password, was as a patch in Codehaus JIRA.

http://jira.codehaus.org/secure/attachment/23421/CONTINUUM-956.patch

In short, Passwords are stored as SHA-1 hashes in the SA.CONTINUUMUSER table.

So

1. Shutdown continuum. 2. create a new SHA-1 password eg echo ‘mypassword’ | openssl dgst -sha1 3. Download a copy of Apache Derby 4. DERBY_HOME to this location eg export DERBY_HOME=/Users/ieb/db-derby-10.2.2.0-bin 5. Execute the Embedded Classpath setup eg db-derby-10.2.2.0-bin/bin/setEmbeddedCP 6. Start up ij eg db-derby-10.2.2.0-bin/bin/ij 7. At the ij prompt connect to your continnum databse eg connect ‘jdbc:derby:/Users/ieb/continuum/apps/continuum/database’; 8. select * from SA.CONTINUUMUSER; 9. UPDATE SA.CONTINUUMUSER set HASH_PASSWORD = ‘the sha1 from step 2’ where ACCOUNT_ID = 6;

You will need to check the steps in 8 and 9 for syntax and schema names. ACCOUNT_ID = 6 represents the account where the password is being reset.

10. commit; 11. exit;

Then restart continuum and login with ‘mypassword’ or whatever you used in step 2.

If that fails… you may have to drop the DB and restart.

To avoid this…. always have 2 admin users… then if one fails you can always use the other one to reset things.

Advertisements




Content Hosting Handler

16 01 2007

We now have a patch for trunk for Content Hosting Handler.. that works!

Thanks must go to John Fawcett who has been working hard at Caret for the past few months (part time) to eliminate all the issues and get it all working. As you may know the default Content Hosting Service implementation is a large area of Sakai and there are some complexities that make it difficult to extend.

So its now possible to provide an implementation of the ContentHostingHandler, inject it into the ComponentManager and then add a resource with a property naming the handler by spring id.

The content of the resource is then passed to that handler before the ContentEntity is resolved, hence ‘mounting’ the virtual resource.

We have done a simple read only filesystem implementation that allows the ‘mounting’ of a disk local to the Sakai server into resource using a simple XML file.

Our next target is a DSpace ContentHostingHandler.





GET urls are latin-1 encoded.

12 01 2007

Looks like get urls are latin-1 encoded.

Wrapping the request and recoding looks like it works.

protected void doGet(final HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // GET doesnt do UTF-8 encoding even URL, take the default encoding of the machine HttpServletRequestWrapper httprequest = new HttpServletRequestWrapper(request) { @Override public String getParameter(String name) { String param = request.getParameter(name); try { return new String(param.getBytes(“ISO-8859-1″),”UTF-8”); } catch (UnsupportedEncodingException e) { return param; } } }; execute(httprequest, response); }





UTF-8 Encoding on Gets with tomcat.

12 01 2007

Looks like browsers dont UTF encode Gets correctly, or at least that whats observed. Take a form, make it a GET and put some UTF-chars in … eg 中国的网页

Then when it gets to the server ( in this case tomcat it comes out badly coded).

If you change the GET to a POST, encoding works Ok. It could be a tomcat issue assuming the get url is something it inst or it could be something more fundamental. It looks like it happens even when the URL is URL encoded.





UTF-8 Encoding on Gets with tomcat.

12 01 2007

Looks like browsers dont UTF encode Gets correctly, or at least that whats observed. Take a form, make it a GET and put some UTF-chars in … eg 中国的网页

Then when it gets to the server ( in this case tomcat it comes out badly coded).

If you change the GET to a POST, encoding works Ok. It could be a tomcat issue assuming the get url is something it inst or it could be something more fundamental. It looks like it happens even when the URL is URL encoded.





UTF-8 Encoding on Gets with tomcat.

12 01 2007

Looks like browsers dont UTF encode Gets correctly, or at least that whats observed. Take a form, make it a GET and put some UTF-chars in … eg 中国的网页

Then when it gets to the server ( in this case tomcat it comes out badly coded).

If you change the GET to a POST, encoding works Ok. It could be a tomcat issue assuming the get url is something it inst or it could be something more fundamental. It looks like it happens even when the URL is URL encoded.





Powerbook Hard Disks.

9 01 2007

If you find that your Powerbook sounds like a distant helicopter when you carry it around, replace your hard disk… now before you loose it! Apparently the Toshiba 60G disks bearings in G4’s fail with too much heat. I thought mine was just the fan…. until it sounded more like a Chinook overhead. http://www.raf.mod.uk/equipment/chinook.html