secondary name exists in binary,can it be removed?

[o2e]

I used @NameInDb to rename the field names in the DB, but after testing in the security department I found that the member names of the entity still exist in the binary. I changed the name in the entity again and objectbox still works. After using NameInDb, is the actual member name of the entity still valuable? For me, it takes extra space and leaks my actual mapped names of entity members, I really like objectbox, I'm trying to modify the generation tool, but no progress. Is there an easy way to configure it? I don't seem to find it in the documentation (maybe I'm missing something )

objectbox ver:3.1.1
work on android project

[greenrobot-team]

The @NameInDb annotation is kept in compiled code so the annotation processor can access it (if I remember correctly). Edit: never mind, it shouldn't be kept, odd.

Anyhow, maybe using the @Uid annotation is what you are looking for: https://docs.objectbox.io/advanced/data-model-updates Then code can refer to the UID instead of the name of a property.

[o2e]

I read this documentation on UIDs carefully and he does have the ability to change the field names at will. It fits the description of the documentation.

But my idea is to remove the "secondaryName" content written in the DB binary when it is first generated, I have a table as shown in the code below

Then is a simple view of the DB binary file

As you can see, it contains the names of the members of my entity inside. Our security engineers believe that if @NameInDb is used there should not be an actual member name.

For this reason I modified the "buildEntityAccount" logic in "MyObjectBox" using a hook, so that "secondaryName("uin ")" into an empty string for testing, and it doesn't seem to affect the operation of objectbox.

I think removing "secondaryName" is harmless and beneficial, it reduces the binary footprint and improves the security of the program to some extent (security engineers say it prevents hackers from tracing sensitive logic through field names backwards, which makes the program less secure), I agree (of course I don't know if this will affect the intuitiveness of debug output).

Now that I can make it execute with the logic I want through a hook inside the program, would you consider removing the "secondaryName" field that is written into the binary?

[greenrobot-team]

The secondary name needs to be passed to the native component so it can properly create entity objects and set data to fields, e.g. for get or query. It's odd though that it is actually stored in the database.

Did you try this with a new (vs. existing) database?

[o2e]

I have tried two scenarios,

1、using the original logic to create a good database and insert a new row, then prevent the value of "secondaryName" to pass in and then insert and query, objectbox does not report errors, insert and query (including conditional query) everything is normal.

2、Use the logic after my hook ( prevent the value of "secondaryName" from being passed in ) and then create a database and insert new data and query, no error occurs. Then unhook, use the original logic to query and insert all normal. Because I renamed the database using @NameInDb.

MyObjectBox hard-coded the member name of the entity when it was generated, and usually the apk will be obfuscated after the Android development, the member name of the entity at this time already does not match the name generated by MyObjectBox, he relies on @NameInDb query, "secondaryName" has no real value

What I think is that when you have @NameInDb. should give up writing "secondaryName" to the binary data

This is just my personal opinion, but it doesn't stop me from loving objectbox

[greenrobot-team]

Sorry, more details: it works in your case because ObjectBox can use the all argument constructor provided by the Kotlin data class to create the Account object. But with ObjectBox it's also possible to just provide a default or other constructor (also think of Java using getter/setter), then ObjectBox will access the fields/properties directly. In that case obfuscation will also break creating an object.

Example:

@Entity
data class DefaultConstructorExample(
    @Id var id: Long = 0,
    var name: String = "",
    @Transient var total: Int = 0
)