Writing a binary field to the database prior to logging in

For the project I am working on, we've written our own login procedure. Due to a bug I have been testing some stuff and encountered the following problem. DigipassObj is a Mendix object (Digipass) which is retrieved when an user tries to log in. It gets manipulated and then has to be written back to the database, specifically the DigipassDataBinary field (which, obviously, is a Binary field in Mendix as well). As per: IContext context = Core.getSystemContext(); ByteArrayOutputStream os = new ByteArrayOutputStream(248); DigipassObj.getDigipassDataBinary(context, os); byte[] DigipassDataByte = os.toByteArray(); //some lines where DigipassDataByte is manipulated ByteArrayInputStream is = new ByteArrayInputStream(DigipassDataByte); DigipassObj.setDigipassDataBinary(context, is, DigipassDataByte.length); The problem, however, seems to be that the context is null, possibly because the user hasn't logged in yet and security prevents him/her from manipulating data. Strangely enough retrieving the object with .getDigipassDataBinary(context, os); works fine but writing the binary field with .setDigipassDataBinary(context, is, DigipassDataByte.length); throws a NullPointerException while the 2nd and 3rd argument both aren't null values (is: binary object, DigipassDataByte.length: 248 respectively). Does security prevent an user from writing anything to the database while not logged in yet, or is this a different issue? Something concerning binary values maybe... any suggestions on how to write this binary object into the database would be much appreciated.
2 answers

A NullpointerException can be caused by a lot of different things, not necessarily the arguments you're passing. Considering the fact that you can retrieve the field normally but can't write to it, I suspect that it's a bug.

As a workaround you can encode the data in base64 and store it as a string in the database, or use a filedocument (using binary fields in the database isn't recommended)


You should always have a (valid) context when interacting with the database, so that's probably what's causing your problem.

Depending on the exact situation, you might want to look at

public static IContext getSystemContext()

in Core to get a valid context.