ConnectID Foundation #2847
ConnectID Foundation #2847
Conversation
Added database models and helper class for storage (with upgrader). Added network helper class to wrap common functionality for API calls. Added code to support encryption via a key stored in the Android Keystore.
…ort test framework
OrangeAndGreen
requested review from
ctsims,
shubham1g5,
avazirna and
pm-dimagi
|
@damagatchi retest this please |
There was a problem hiding this comment.
Did a first pass without getting into too much of implementation details, things look mostly good to me overall. A couple things that would be nice to add in this PR
- Java docs for public apis of DB, Network and encryption helpers
- There are a couple places with
LEGACY..comments, it would be nice to add info on when in future we think those legacy pathways can be eliminated. (or atleast what CC version does that legacy pathway tie to)
| super.onConfigurationChanged(newConfig); | ||
| LocalePreferences.saveDeviceLocale(newConfig.locale); |
app/src/org/commcare/android/database/connect/models/ConnectAppRecord.java
Outdated
Show resolved
Hide resolved
| record.jobId = jobId; | ||
| record.date = json.has(META_DATE) ? ConnectNetworkHelper.parseDate(json.getString(META_DATE)) : new Date(); | ||
| record.score = json.has(META_SCORE) ? json.getInt(META_SCORE) : -1; | ||
| record.passingScore = json.has(META_PASSING_SCORE) ? json.getInt(META_PASSING_SCORE) : -1; | ||
| record.passed = json.has(META_PASSED) && json.getBoolean(META_PASSED); |
There was a problem hiding this comment.
for this and rest of the api response parsing, I think we should error out if any of the mandatory fields are not present or in the wrong format (date here) . Otherwise we will bury api response errors until there is an error in user workflow and these errors would be much harder to know/surface/debug in that case. Our tolerance policy in case of api data errors should be zero tolerance and we should crash out the app in such cases. (This will need proper testing before deploy though)
| private static KeyStore getKeystore() throws KeyStoreException, CertificateException, | ||
| IOException, NoSuchAlgorithmException { | ||
| if (keystoreSingleton == null) { | ||
| keystoreSingleton = KeyStore.getInstance(KEYSTORE_NAME); | ||
| keystoreSingleton.load(null); | ||
| } | ||
|
|
||
| return keystoreSingleton; | ||
| } |
There was a problem hiding this comment.
Think this needs to be threadsafe, a clever way to do it would be to have the singleton reference in a inner class (From Chatgpt - The inner class is loaded only when it's referenced, and since class loading is thread-safe in Java, it guarantees that the instance is created lazily and in a thread-safe manner)
public class Singleton {
// Private constructor prevents instantiation from other classes
private Singleton() {}
// The inner static class responsible for holding the singleton instance
private static class SingletonHelper {
// The final static instance, will be initialized when the class is loaded
private static final Singleton INSTANCE = new Singleton();
}
// Public method to access the instance
public static Singleton getInstance() {
return SingletonHelper.INSTANCE;
}
}
There was a problem hiding this comment.
Ah, yup, like we've done in other places. Commit
| */ | ||
| public class EncryptionKeyProvider { | ||
| private static final String KEYSTORE_NAME = "AndroidKeyStore"; | ||
| private static final String SECRET_NAME = "secret"; |
There was a problem hiding this comment.
would be nice to have a more descriptive name here - "cc_encryption_key` , but would not do so if it means adding more code to be backward compatible.
There was a problem hiding this comment.
Ah, yeah, at this point we'd have to make it upgradeable or backward compatible for existing users
There was a problem hiding this comment.
no need to change in that case. though can we add a comment here that this should not be renamed due to backward compatibility.
| } | ||
|
|
||
| @SuppressLint("InlinedApi") //Suppressing since we check the API version elsewhere | ||
| public static String getTransformationString(boolean useRsa) { |
There was a problem hiding this comment.
nit: maybe pass the encryption type here directly instead if useRsa (aes vs rsa)
|
|
||
| byte[] result = new byte[PASSPHRASE_LENGTH]; | ||
|
|
||
| while (true) { |
There was a problem hiding this comment.
Any idea what's the average number of iterations it will take to arrive at a passphrase that doesn't contain zero ? Mostly thinking if it can result into a near infinite loop.
…nto dv/connectid_foundation
Deleted some commented lines. Better exception logging in a few spots.
…stead of retrieving it again.
…sing the configured key server and protocol
WalkthroughThe pull request introduces significant updates to the CommCare application, primarily focusing on the integration of a new "Connect" feature, which includes the addition of multiple string resources in the Additionally, a new Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's limits when posting large numbers of comments.
🛑 Comments failed to post (64)
app/src/org/commcare/connect/network/IApiCallback.java (1)
10-14: 🛠️ Refactor suggestion
Add method-level documentation and consider additional parameters
The method signatures look good, but they need documentation and might benefit from additional context.
+ /** + * Handles successful API responses. + * @param responseCode HTTP response code + * @param responseData Response body as an InputStream + */ void processSuccess(int responseCode, InputStream responseData); + /** + * Handles API request failures with error details. + * @param responseCode HTTP error code + * @param e Exception containing error details + */ void processFailure(int responseCode, IOException e); + /** + * Handles network connectivity failures or timeout issues. + */ void processNetworkFailure(); + /** + * Handles errors related to incompatible API versions. + */ void processOldApiError();Also, consider:
- Adding
@Nullableannotation for theIOExceptionparameter- Including request context (e.g., request type or endpoint) in callbacks
- Adding a method for handling authentication failures specifically
Committable suggestion skipped: line range outside the PR's diff.
app/src/org/commcare/android/database/connect/models/ConnectJobDeliveryRecordV2.java (3)
60-72: 🛠️ Refactor suggestion
Consider enforcing immutability and adding a builder
The class appears to be designed for immutability (no setters), but:
- Fields aren't marked as
final- No constructor with parameters is provided
- No builder pattern for easier object creation
Consider:
- Making fields
final- Adding a builder or constructor with parameters
- Adding validation in the construction process
Example builder pattern implementation:
public static class Builder { private int jobId; private int deliveryId; private Date date; // ... other fields public Builder withJobId(int jobId) { this.jobId = jobId; return this; } // ... other builder methods public ConnectJobDeliveryRecordV2 build() { // Add validation here ConnectJobDeliveryRecordV2 record = new ConnectJobDeliveryRecordV2(); record.jobId = this.jobId; // ... set other fields return record; } }
1-72:
⚠️ Potential issueAdd input validation and use immutable date representation
Security and robustness concerns:
- The
Dateclass is mutable. Consider usingInstantorLocalDateTimefrom java.time package- Add validation for:
- Status values (consider using an enum)
- Non-null checks for required fields
- Format validation for entityId
Example validation in builder:
public ConnectJobDeliveryRecordV2 build() { Objects.requireNonNull(date, "date cannot be null"); Objects.requireNonNull(status, "status cannot be null"); Objects.requireNonNull(entityId, "entityId cannot be null"); // Add more validation as needed // ... }
54-57: 🛠️ Refactor suggestion
Fix naming convention violation
The field
entitynameviolates Java naming conventions. It should be camelCase.- private String entityname; + private String entityName;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.@Persisting(8) @MetaField(META_ENTITY_NAME) private String entityName; @Persisting(9)app/src/org/commcare/android/database/connect/models/ConnectJobRecordV2.java (4)
95-100:
⚠️ Potential issueAdd @metafield annotations for date fields
The following date fields lack @metafield annotations:
- lastUpdate
- lastLearnUpdate
- lastDeliveryUpdate
This might affect database queries and schema migrations.
102-104:
⚠️ Potential issueInitialize fields in constructor
The empty constructor leaves all fields uninitialized. Consider:
- Adding parameter validation in constructor
- Initializing fields with default values
- Making the constructor private if it's only for ORM
117-117:
⚠️ Potential issueImprove error handling in getPaymentAccrued()
The method could throw NumberFormatException when parsing invalid strings. Consider:
- public int getPaymentAccrued() { return paymentAccrued != null && paymentAccrued.length() > 0 ? Integer.parseInt(paymentAccrued) : 0; } + public int getPaymentAccrued() { + if (paymentAccrued == null || paymentAccrued.isEmpty()) { + return 0; + } + try { + return Integer.parseInt(paymentAccrued); + } catch (NumberFormatException e) { + // Log error + return 0; + } + }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public int getPaymentAccrued() { if (paymentAccrued == null || paymentAccrued.isEmpty()) { return 0; } try { return Integer.parseInt(paymentAccrued); } catch (NumberFormatException e) { // Log error return 0; } }
89-91: 🛠️ Refactor suggestion
Consider storing paymentAccrued as numeric type
The
paymentAccruedfield is stored as String but represents a numeric value. This could lead to:
- Parsing errors (handled in getPaymentAccrued())
- Inefficient database queries
- Validation issues
Consider changing to:
- private String paymentAccrued; + private int paymentAccrued;Committable suggestion skipped: line range outside the PR's diff.
app/src/org/commcare/android/database/connect/models/ConnectJobRecordV4.java (3)
147-149:
⚠️ Potential issueRemove duplicate assignment of lastWorkedDate
The lastWorkedDate field is assigned twice.
newRecord.lastWorkedDate = oldRecord.getLastWorkedDate(); -newRecord.lastWorkedDate = oldRecord.getLastWorkedDate();📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.newRecord.lastWorkedDate = oldRecord.getLastWorkedDate(); newRecord.organization = oldRecord.getOrganization();
88-91: 🛠️ Refactor suggestion
Consider using Integer type for paymentAccrued
Storing numeric values as strings can lead to parsing errors and validation issues. Consider using an Integer type instead.
@Persisting(16) @MetaField(META_ACCRUED) -private String paymentAccrued; +private Integer paymentAccrued;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.@Persisting(16) @MetaField(META_ACCRUED) private Integer paymentAccrued; @Persisting(17)
134-161: 💡 Codebase verification
🛠️ Refactor suggestion
Based on the gathered information, I can now provide the final response:
Migration method needs validation and documentation improvements
The review suggestions are valid as:
- The V2 class shows that fields like
jobId,title, and other critical data are persisted but the migration doesn't validate them- There's no validation logic in V4 class for the migrated data
- The comment "Used for app db migration only" is insufficient to explain the
dateClaimedinitialization- No null checks are present despite handling multiple string and date fields
Specific recommendations:
- Add null checks for
title,description,organization, and date fields- Document why
dateClaimedis set to current date in migration (likely represents migration timestamp)- Add validation for numeric fields (
jobId,budgetPerVisit, etc.) to ensure they're within valid ranges- Consider adding a validation method in V4 to ensure data integrity post-migration
🔗 Analysis chain
Enhance migration method robustness
The fromV2 method needs improvements:
- Add validation for copied data
- Document why dateClaimed is set to current date
- Consider adding error handling for null values
Also, verify that V2 to V4 migration handles all edge cases correctly.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for V2 class definition to compare field types ast-grep --pattern 'class ConnectJobRecordV2 { $$$ }' # Look for any existing migration tests rg -l "ConnectJobRecordV2.*ConnectJobRecordV4" --type javaLength of output: 118
Script:
#!/bin/bash # Search for V2 class with a more flexible pattern ast-grep --pattern 'class ConnectJobRecordV2' # Search for V2 class with ripgrep to get more context rg -A 10 "class ConnectJobRecordV2" --type java # Look for any test files related to ConnectJobRecord fd -e java test | xargs rg "ConnectJobRecord" # Search for any usage of fromV2 method rg "fromV2.*ConnectJobRecord" --type javaLength of output: 2269
Script:
#!/bin/bash # Get the full content of V2 class to check field types and nullability rg -A 50 "class ConnectJobRecordV2" app/src/org/commcare/android/database/connect/models/ConnectJobRecordV2.java # Look for any migration tests specifically rg -B 5 -A 10 "fromV2.*ConnectJobRecord" --type java # Check if there are any existing validation methods in V4 rg "validate|isValid" app/src/org/commcare/android/database/connect/models/ConnectJobRecordV4.javaLength of output: 4263
app/src/org/commcare/android/database/connect/models/ConnectLinkedAppRecordV3.java (5)
10-20: 🛠️ Refactor suggestion
Enhance documentation and consider more specific table name.
- The class documentation should explain:
- Why this is V3 and what changes from previous versions
- Migration path from previous versions
- Encryption expectations for sensitive data
- The table name "app_info" is too generic. Consider a more specific name like "connect_linked_apps" to clearly indicate its purpose.
/** * DB model holding info for an HQ app linked to ConnectID + * + * Version 3 of the linked app record introduces: + * - HQ token management + * - Worker linking status + * + * Migration from V2: + * - Added hqToken and hqTokenExpiration fields + * - Added workerLinked status + * + * Security: Password and token fields should be encrypted at rest * * @author dviggiano */ @Table(ConnectLinkedAppRecordV3.STORAGE_KEY) public class ConnectLinkedAppRecordV3 extends Persisted { /** - * Name of database that stores Connect user records + * Name of database table that stores ConnectID linked app records */ - public static final String STORAGE_KEY = "app_info"; + public static final String STORAGE_KEY = "connect_linked_apps";📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements./** * DB model holding info for an HQ app linked to ConnectID * * Version 3 of the linked app record introduces: * - HQ token management * - Worker linking status * * Migration from V2: * - Added hqToken and hqTokenExpiration fields * - Added workerLinked status * * Security: Password and token fields should be encrypted at rest * * @author dviggiano */ @Table(ConnectLinkedAppRecordV3.STORAGE_KEY) public class ConnectLinkedAppRecordV3 extends Persisted { /** * Name of database table that stores ConnectID linked app records */ public static final String STORAGE_KEY = "connect_linked_apps";
37-38: 🛠️ Refactor suggestion
Ensure thread-safety for date handling.
The
hqTokenExpirationfield uses mutableDatewhich could lead to thread-safety issues.- @Persisting(6) - private Date hqTokenExpiration; + @Persisting(6) + private final long hqTokenExpirationTimestamp;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.@Persisting(6) private final long hqTokenExpirationTimestamp;
25-38:
⚠️ Potential issueCritical: Implement secure storage for sensitive data.
The password and token fields are stored as plain Strings, which:
- Remain in memory until garbage collection
- Could be written to disk unencrypted
- May appear in logs or crash reports
Consider these security improvements:
- @Persisting(3) - private String password; + @Persisting(3) + @Encrypted + private char[] password; - @Persisting(value = 5, nullable = true) - private String hqToken; + @Persisting(value = 5, nullable = true) + @Encrypted + private char[] hqToken;Committable suggestion skipped: line range outside the PR's diff.
40-67: 🛠️ Refactor suggestion
Add input validation and improve data encapsulation.
Several improvements needed for safer data handling:
- Password setter lacks validation
- Date object returned without defensive copying
- No null checks for token access
Apply these improvements:
public void setPassword(String password) { + if (password == null || password.isEmpty()) { + throw new IllegalArgumentException("Password cannot be null or empty"); + } this.password = password; } public String getHqToken() { + return hqToken != null ? hqToken : ""; } public Date getHqTokenExpiration() { - return hqTokenExpiration; + return hqTokenExpiration != null ? new Date(hqTokenExpiration.getTime()) : new Date(); }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public ConnectLinkedAppRecordV3() { hqTokenExpiration = new Date(); } public String getAppId() { return appId; } public String getUserId() { return userId; } public String getPassword() { return password; } public void setPassword(String password) { if (password == null || password.isEmpty()) { throw new IllegalArgumentException("Password cannot be null or empty"); } this.password = password; } public boolean getWorkerLinked() { return workerLinked; } public String getHqToken() { return hqToken != null ? hqToken : ""; } public Date getHqTokenExpiration() { return hqTokenExpiration != null ? new Date(hqTokenExpiration.getTime()) : new Date(); }
1-68: 💡 Codebase verification
Based on the gathered information, I can now provide the final response:
Security measures need to be enhanced for sensitive data storage
The current implementation of
ConnectLinkedAppRecordV3and its subsequent versions (V8, V9) store sensitive data (password, tokens) without proper encryption annotations. While there is anEncryptionKeyProvideravailable in the codebase that uses Android Keystore for secure key management, it's not being utilized for encrypting the sensitive fields in these models.Key findings:
- Password and token fields are stored as plain String without encryption annotations
EncryptionKeyProviderexists but isn't integrated with these models- V9 introduces
usingLocalPassphraseflag but still lacks encryption for sensitive data🔗 Analysis chain
Verify encryption integration with EncryptionKeyProvider.
Since this class handles sensitive data and the PR mentions EncryptionKeyProvider, we should verify the encryption implementation across related classes.
Let me gather more information about the encryption implementation by checking the related files found.
Let me check one more aspect to verify if there are any encryption annotations or security measures in the upgraded versions of this record.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for encryption annotations and key provider usage echo "Checking for encryption patterns in related files..." rg -l "EncryptionKeyProvider" app/src/ rg -l "@Encrypted" app/src/org/commcare/android/database/connect/models/ echo "Checking for similar sensitive data patterns..." ast-grep --pattern 'class $_ { $$$ @Persisting($_) private String password; $$$ }'Length of output: 572
Script:
#!/bin/bash # Check EncryptionUtils and EncryptionKeyProvider implementation echo "Checking EncryptionUtils implementation..." rg -A 5 "class EncryptionUtils" app/src/org/commcare/utils/EncryptionUtils.java echo "Checking password-related encryption methods..." rg -A 5 "password" app/src/org/commcare/utils/EncryptionUtils.java echo "Checking EncryptionKeyProvider interface..." cat app/src/org/commcare/utils/EncryptionKeyProvider.java echo "Checking ConnectLinkedAppRecordV3 usage..." rg -A 5 "ConnectLinkedAppRecordV3" app/src/Length of output: 12699
Script:
#!/bin/bash # Check V8 and V9 implementations for encryption annotations echo "Checking ConnectLinkedAppRecordV8 implementation..." cat app/src/org/commcare/android/database/connect/models/ConnectLinkedAppRecordV8.java echo "Checking ConnectLinkedAppRecordV9 implementation..." cat app/src/org/commcare/android/database/connect/models/ConnectLinkedAppRecordV9.java echo "Checking for @Encrypted annotations in the codebase..." rg -l "@Encrypted" app/src/Length of output: 8004
app/src/org/commcare/android/database/connect/models/ConnectJobLearningRecord.java (4)
67-67: 🛠️ Refactor suggestion
Add validation to setLastUpdate
The setLastUpdate method accepts any Date without validation and stores a mutable reference.
Add validation and defensive copying:
- public void setLastUpdate(Date date) { lastUpdate = date; } + public void setLastUpdate(Date date) { + if (date == null) { + throw new IllegalArgumentException("LastUpdate date cannot be null"); + } + lastUpdate = (Date)date.clone(); + }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public void setLastUpdate(Date date) { if (date == null) { throw new IllegalArgumentException("LastUpdate date cannot be null"); } lastUpdate = (Date)date.clone(); }
64-65: 🛠️ Refactor suggestion
Add missing getters and ensure thread safety
The class exposes only moduleId and date getters, missing getters for jobId, duration, and lastUpdate.
Add missing getters and ensure thread safety:
- public Date getDate() { return date; } + public Date getDate() { return (Date)date.clone(); } + public String getDuration() { return duration; } + public int getJobId() { return jobId; } + public Date getLastUpdate() { return (Date)lastUpdate.clone(); }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public int getModuleId() { return moduleId; } public Date getDate() { return (Date)date.clone(); } public String getDuration() { return duration; } public int getJobId() { return jobId; } public Date getLastUpdate() { return (Date)lastUpdate.clone(); }
51-62:
⚠️ Potential issueImprove fromJson method safety and validation
The current implementation has several potential improvements:
- Date objects are mutable and not thread-safe
- No validation for negative jobId
- Silent fallback to default values might hide issues
Consider applying these improvements:
public static ConnectJobLearningRecord fromJson(JSONObject json, int jobId) throws JSONException, ParseException { + if (jobId <= 0) { + throw new IllegalArgumentException("Invalid jobId: " + jobId); + } + if (json == null) { + throw new IllegalArgumentException("JSON object cannot be null"); + } ConnectJobLearningRecord record = new ConnectJobLearningRecord(); - record.lastUpdate = new Date(); + record.lastUpdate = (Date)new Date().clone(); // Defensive copy record.jobId = jobId; - record.date = json.has(META_DATE) ? ConnectNetworkHelper.parseDate(json.getString(META_DATE)) : new Date(); + record.date = (Date)(json.has(META_DATE) ? + ConnectNetworkHelper.parseDate(json.getString(META_DATE)) : + new Date()).clone(); // Defensive copy record.moduleId = json.has(META_MODULE) ? json.getInt(META_MODULE) : -1; record.duration = json.has(META_DURATION) ? json.getString(META_DURATION) : ""; return record; }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public static ConnectJobLearningRecord fromJson(JSONObject json, int jobId) throws JSONException, ParseException { if (jobId <= 0) { throw new IllegalArgumentException("Invalid jobId: " + jobId); } if (json == null) { throw new IllegalArgumentException("JSON object cannot be null"); } ConnectJobLearningRecord record = new ConnectJobLearningRecord(); record.lastUpdate = (Date)new Date().clone(); // Defensive copy record.jobId = jobId; record.date = (Date)(json.has(META_DATE) ? ConnectNetworkHelper.parseDate(json.getString(META_DATE)) : new Date()).clone(); // Defensive copy record.moduleId = json.has(META_MODULE) ? json.getInt(META_MODULE) : -1; record.duration = json.has(META_DURATION) ? json.getString(META_DURATION) : ""; return record; }
42-44: 💡 Codebase verification
🛠️ Refactor suggestion
Add duration format validation
Based on the codebase analysis, the duration field in ConnectJobLearningRecord is stored as a String without any validation, and there are no getter/setter methods implementing format checks. This could indeed lead to inconsistent data storage as the review suggests.
- The field is populated directly from JSON using
json.getString(META_DURATION)without any format validation- No validation methods or standardized format are enforced
- Other duration-related fields in the codebase (for media, calls, etc.) use long values in milliseconds, suggesting a potential standardization opportunity
Consider:
- Adding format validation before storing the duration
- Using a standardized format (e.g., milliseconds as long) consistent with other duration fields in the codebase
- Implementing getter/setter methods with proper validation
🔗 Analysis chain
Add duration format validation
The duration field is stored as a String without any format validation. This could lead to inconsistent data storage.
Let's check if there's any duration format validation in the codebase:
Consider:
- Adding duration format validation
- Using a dedicated Duration type or standardized format
Let me analyze the usage of duration in the codebase to make a final determination.
From the search results, I can see that:
The
ConnectJobLearningRecordclass uses duration as a String field, and when creating from JSON it's simply assigned without validation:record.duration = json.has(META_DURATION) ? json.getString(META_DURATION) : "";Other duration usages in the codebase are primarily for:
- Media playback duration (as long values in milliseconds)
- Call duration tracking (as long values in milliseconds)
- Animation duration (as long values in milliseconds)
- Session duration (as seconds converted to milliseconds)
Let me verify if there are any setters or validation methods for the duration field:
Let me try one more search to find any getters/setters for the duration field:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for duration format validation or usage patterns rg -A 5 "META_DURATION|duration" --type javaLength of output: 15772
Script:
#!/bin/bash # Search for duration-related methods in ConnectJobLearningRecord ast-grep --pattern 'class ConnectJobLearningRecord { $$$ $duration($$$) { $$$ } $$$ }'Length of output: 100
Script:
#!/bin/bash # Search for duration-related methods in ConnectJobLearningRecord rg -A 2 "getDuration|setDuration" app/src/org/commcare/android/database/connect/models/ConnectJobLearningRecord.javaLength of output: 118
app/src/org/commcare/android/database/connect/models/ConnectLinkedAppRecordV9.java (3)
43-44: 🛠️ Refactor suggestion
Add validation for token expiration date.
The
hqTokenExpirationfield should be validated to ensure it's not set to a past date. Consider adding validation in the setter or constructor.public Date getHqTokenExpiration() { return hqTokenExpiration; } + +private void setHqTokenExpiration(Date expiration) { + if (expiration != null && expiration.before(new Date())) { + throw new IllegalArgumentException("Token expiration cannot be in the past"); + } + this.hqTokenExpiration = expiration; +}Also applies to: 92-94
65-69: 🛠️ Refactor suggestion
Enhance constructor with proper initialization and validation.
The current constructor:
- Doesn't initialize all fields
- Lacks validation for required fields
- Doesn't document the default values
Consider adding parameter validation and complete field initialization.
public ConnectLinkedAppRecordV9() { + // Initialize required fields + this.workerLinked = false; + this.connectIdLinked = false; + this.linkOffered1 = false; + this.linkOffered2 = false; + this.usingLocalPassphrase = true; + + // Initialize dates to current time hqTokenExpiration = new Date(); linkOfferDate1 = new Date(); linkOfferDate2 = new Date(); }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public ConnectLinkedAppRecordV9() { // Initialize required fields this.workerLinked = false; this.connectIdLinked = false; this.linkOffered1 = false; this.linkOffered2 = false; this.usingLocalPassphrase = true; // Initialize dates to current time hqTokenExpiration = new Date(); linkOfferDate1 = new Date(); linkOfferDate2 = new Date(); }
108-126: 🛠️ Refactor suggestion
Enhance migration method safety.
The
fromV8method needs additional safety measures:
- Validate the old record is not null
- Document the default value choice for
usingLocalPassphrase- Consider adding migration validation
public static ConnectLinkedAppRecordV9 fromV8(ConnectLinkedAppRecordV8 oldRecord) { + if (oldRecord == null) { + throw new IllegalArgumentException("Old record cannot be null"); + } + ConnectLinkedAppRecordV9 newRecord = new ConnectLinkedAppRecordV9(); newRecord.appId = oldRecord.getAppId(); + if (newRecord.appId == null || newRecord.appId.isEmpty()) { + throw new IllegalStateException("Invalid migration: appId is required"); + } // ... rest of the migration code ... // Default to true as per security requirements for V9 newRecord.usingLocalPassphrase = true; return newRecord; }Committable suggestion skipped: line range outside the PR's diff.
app/src/org/commcare/android/database/connect/models/ConnectJobDeliveryRecord.java (4)
70-73:
⚠️ Potential issueInitialize string fields to prevent NPEs.
The constructor only initializes date fields, leaving string fields as null. This could lead to NPEs in code that assumes these fields are non-null.
Consider this improvement:
public ConnectJobDeliveryRecord() { date = new Date(); lastUpdate = new Date(); + status = ""; + unitName = ""; + slug = ""; + entityId = ""; + entityName = ""; + reason = ""; }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public ConnectJobDeliveryRecord() { date = new Date(); lastUpdate = new Date(); status = ""; unitName = ""; slug = ""; entityId = ""; entityName = ""; reason = ""; }
117-132: 🛠️ Refactor suggestion
Improve version migration safety.
The
fromV2method has potential issues:
- No null check for oldRecord parameter
- Direct date assignment could share mutable state
- No validation of migrated data
Consider these improvements:
public static ConnectJobDeliveryRecord fromV2(ConnectJobDeliveryRecordV2 oldRecord) { + if (oldRecord == null) { + throw new IllegalArgumentException("Old record cannot be null"); + } + ConnectJobDeliveryRecord newRecord = new ConnectJobDeliveryRecord(); newRecord.jobId = oldRecord.getJobId(); newRecord.deliveryId = oldRecord.getDeliveryId(); - newRecord.date = oldRecord.date; + newRecord.date = oldRecord.date != null ? new Date(oldRecord.date.getTime()) : new Date(); // ... rest of the migrations ... + // Validate migrated record + if (newRecord.jobId <= 0 || newRecord.deliveryId <= 0) { + throw new IllegalStateException("Invalid migration: negative or zero IDs"); + } return newRecord; }Committable suggestion skipped: line range outside the PR's diff.
75-102:
⚠️ Potential issueImprove error handling in fromJson method.
The method has several potential issues:
- Returns null on error, which could cause NPEs in calling code
- Catches all exceptions generically
- Date parsing errors might be silently ignored
Consider these improvements:
- Create specific exceptions for different failure cases
- Add validation for required fields
- Document the possible failure scenarios
-public static ConnectJobDeliveryRecord fromJson(JSONObject json, int jobId) throws JSONException, ParseException { +public static ConnectJobDeliveryRecord fromJson(JSONObject json, int jobId) throws ConnectDeliveryParseException { if (json == null) { - return null; + throw new ConnectDeliveryParseException("JSON object cannot be null"); } int deliveryId = -1; String dateString = "(error)"; try { // ... existing code ... } catch(JSONException e) { throw new ConnectDeliveryParseException("Invalid JSON format", e); } catch(ParseException e) { throw new ConnectDeliveryParseException("Invalid date format", e); } catch(Exception e) { throw new ConnectDeliveryParseException("Unexpected error", e); } }Committable suggestion skipped: line range outside the PR's diff.
104-115: 🛠️ Refactor suggestion
Review date handling and add setter validation.
The
getDate()method converts dates to local timezone, which could cause issues:
- Original UTC date is modified
- No timezone information is preserved
- No validation in setLastUpdate
Consider these improvements:
-public Date getDate() { return ConnectNetworkHelper.convertDateToLocal(date); } +public Date getDate() { + // Return a defensive copy to prevent modification + return date != null ? new Date(date.getTime()) : null; +} -public void setLastUpdate(Date lastUpdate) { this.lastUpdate = lastUpdate; } +public void setLastUpdate(Date lastUpdate) { + if (lastUpdate == null) { + throw new IllegalArgumentException("lastUpdate cannot be null"); + } + this.lastUpdate = new Date(lastUpdate.getTime()); +}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public int getDeliveryId() { return deliveryId; } public Date getDate() { // Return a defensive copy to prevent modification return date != null ? new Date(date.getTime()) : null; } public String getStatus() { return status; } public String getEntityName() { return entityName; } public void setLastUpdate(Date lastUpdate) { if (lastUpdate == null) { throw new IllegalArgumentException("lastUpdate cannot be null"); } this.lastUpdate = new Date(lastUpdate.getTime()); } public int getJobId() { return jobId; } public String getUnitName() { return unitName; } public String getSlug() { return slug; } public String getEntityId() { return entityId; } public Date getLastUpdate() { return lastUpdate; } public String getReason() { return reason; }app/src/org/commcare/android/database/connect/models/ConnectJobRecord.java (3)
178-178:
⚠️ Potential issuePossible NullPointerException when initializing
paymentUnitsIn the
fromJsonmethod, the JSON arrayunitsJsonis assumed to be present. IfMETA_PAYMENT_UNITSis not included in the JSON, this could result in aJSONException.Add a null check to ensure
unitsJsonexists:-JSONArray unitsJson = json.getJSONArray(META_PAYMENT_UNITS); +JSONArray unitsJson = json.has(META_PAYMENT_UNITS) ? json.getJSONArray(META_PAYMENT_UNITS) : new JSONArray();Committable suggestion skipped: line range outside the PR's diff.
378-382: 🛠️ Refactor suggestion
Incorrect return type in
setIsUserSuspended(boolean isUserSuspended)The setter method
setIsUserSuspendedreturns a boolean value, but setter methods typically have avoidreturn type.Modify the method to return
void:-public boolean setIsUserSuspended(boolean isUserSuspended) { return this.isUserSuspended=isUserSuspended; } +public void setIsUserSuspended(boolean isUserSuspended) { + this.isUserSuspended = isUserSuspended; +}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public void setIsUserSuspended(boolean isUserSuspended) { this.isUserSuspended = isUserSuspended; } public boolean getIsUserSuspended(){ return isUserSuspended; }
273-273: 🛠️ Refactor suggestion
Inconsistency in storing
paymentAccruedas aString
paymentAccruedis stored as aString, but it represents an integer value for payment accrued. Storing numeric values as strings can lead to parsing issues and impedes mathematical operations.Consider changing the type of
paymentAccruedtoint:-@Persisting(16) -@MetaField(META_ACCRUED) -private String paymentAccrued; +@Persisting(16) +@MetaField(META_ACCRUED) +private int paymentAccrued;Update the getter and setter methods accordingly:
-public int getPaymentAccrued() { return paymentAccrued != null && paymentAccrued.length() > 0 ? Integer.parseInt(paymentAccrued) : 0; } -public void setPaymentAccrued(int paymentAccrued) { this.paymentAccrued = Integer.toString(paymentAccrued); } +public int getPaymentAccrued() { return paymentAccrued; } +public void setPaymentAccrued(int paymentAccrued) { this.paymentAccrued = paymentAccrued; }Committable suggestion skipped: line range outside the PR's diff.
app/src/org/commcare/android/database/connect/models/ConnectJobRecordV7.java (1)
115-117: 🛠️ Refactor suggestion
Empty constructor lacks initialization
The default constructor does not initialize any fields, which could lead to NullPointerExceptions when accessing fields before they are set.
Initialize default values in the constructor or remove it if it is not needed.
app/src/org/commcare/models/database/connect/DatabaseConnectOpenHelper.java (2)
76-76:
⚠️ Potential issuePotential SQL injection vulnerability in
rekeyDBmethodIn the
rekeyDBmethod, the new encryption key is concatenated directly into the SQL query:db.query("PRAGMA rekey = '" + newKeyEncoded + "';");Even though
newKeyEncodedis derived from a Base64-decoded passphrase, concatenating it directly into the SQL statement can pose a security risk. It's safer to use parameterized statements or appropriate methods to avoid any possibility of SQL injection.Suggested fix:
Use
execSQLinstead ofqueryfor executing the PRAGMA statement, which is more appropriate for statements that do not return data:-db.query("PRAGMA rekey = '" + newKeyEncoded + "';"); +db.execSQL("PRAGMA rekey = '" + newKeyEncoded + "';");
77-77:
⚠️ Potential issueAvoid closing the database inside
rekeyDBmethodClosing the database within the
rekeyDBmethod may lead to unexpected behavior if the caller intends to use the database connection afterward:db.close();It's generally advisable to let the caller manage the database lifecycle to prevent accidental closures.
Suggested fix:
Remove the
db.close();call from therekeyDBmethod:- db.close();Ensure that the calling code handles the closing of the database when appropriate.
app/src/org/commcare/connect/network/ConnectNetworkHelper.java (2)
130-130:
⚠️ Potential issueClarify operator precedence in network capability check
To avoid potential logic errors, add parentheses to clarify operator precedence:
-return capabilities != null && capabilities.hasTransport(NetworkCapabilities.TRANSPORT_WIFI) || capabilities.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR); +return capabilities != null && (capabilities.hasTransport(NetworkCapabilities.TRANSPORT_WIFI) || capabilities.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR));📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.return capabilities != null && (capabilities.hasTransport(NetworkCapabilities.TRANSPORT_WIFI) || capabilities.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR));
83-107:
⚠️ Potential issueFix potential concurrency issues with
SimpleDateFormatinstances
SimpleDateFormatis not thread-safe. Using static instances may lead to concurrency issues in a multi-threaded environment. Consider creating newSimpleDateFormatinstances within each method or usingThreadLocalto ensure thread safety.Apply this diff to fix the issue:
-private static final DateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd", Locale.getDefault()); +private static DateFormat getDateFormat() { + return new SimpleDateFormat("yyyy-MM-dd", Locale.getDefault()); +} -public static Date parseDate(String dateStr) throws ParseException { - Date issueDate = dateFormat.parse(dateStr); +public static Date parseDate(String dateStr) throws ParseException { + Date issueDate = getDateFormat().parse(dateStr); return issueDate; } -private static final SimpleDateFormat utcFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", Locale.getDefault()); +private static SimpleDateFormat getUtcFormat() { + return new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", Locale.getDefault()); +} -public static Date convertUTCToDate(String utcDateString) throws ParseException { - utcFormat.setTimeZone(TimeZone.getTimeZone("UTC")); - return utcFormat.parse(utcDateString); +public static Date convertUTCToDate(String utcDateString) throws ParseException { + SimpleDateFormat format = getUtcFormat(); + format.setTimeZone(TimeZone.getTimeZone("UTC")); + return format.parse(utcDateString); } -public static Date convertDateToLocal(Date utcDate) { - utcFormat.setTimeZone(TimeZone.getDefault()); - - try { - String localDateString = utcFormat.format(utcDate); - return utcFormat.parse(localDateString); - } catch (ParseException e) { - return utcDate; - } +public static Date convertDateToLocal(Date utcDate) { + SimpleDateFormat format = getUtcFormat(); + format.setTimeZone(TimeZone.getDefault()); + try { + String localDateString = format.format(utcDate); + return format.parse(localDateString); + } catch (ParseException e) { + return utcDate; + } }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.private static DateFormat getDateFormat() { return new SimpleDateFormat("yyyy-MM-dd", Locale.getDefault()); } public static Date parseDate(String dateStr) throws ParseException { Date issueDate = getDateFormat().parse(dateStr); return issueDate; } private static SimpleDateFormat getUtcFormat() { return new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", Locale.getDefault()); } public static Date convertUTCToDate(String utcDateString) throws ParseException { SimpleDateFormat format = getUtcFormat(); format.setTimeZone(TimeZone.getTimeZone("UTC")); return format.parse(utcDateString); } public static Date convertDateToLocal(Date utcDate) { SimpleDateFormat format = getUtcFormat(); format.setTimeZone(TimeZone.getDefault()); try { String localDateString = format.format(utcDate); return format.parse(localDateString); } catch (ParseException e) { return utcDate; } }app/src/org/commcare/utils/EncryptionUtils.java (2)
135-136:
⚠️ Potential issueHandle Null
IvParameterSpecAppropriatelyWhen initializing the cipher for decryption, passing
nullforIvParameterSpecmight cause aNullPointerExceptionor unexpected behavior. Ensure that the transformation algorithm supports a null IV, or handle this case explicitly.Consider this adjustment:
if (iv != null) { cipher.init(Cipher.DECRYPT_MODE, keyAndTransform.key, new IvParameterSpec(iv)); } else { - cipher.init(Cipher.DECRYPT_MODE, keyAndTransform.key, null); + cipher.init(Cipher.DECRYPT_MODE, keyAndTransform.key); }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.if (iv != null) { cipher.init(Cipher.DECRYPT_MODE, keyAndTransform.key, new IvParameterSpec(iv)); } else { cipher.init(Cipher.DECRYPT_MODE, keyAndTransform.key); }
125-128:
⚠️ Potential issueCorrect Signed Byte Handling in Encrypted Length Calculation
When calculating
encryptedLength, using signed bytes can result in negative values due to byte overflow. To prevent this, mask the bytes with0xFFto treat them as unsigned integers.Apply this change:
-int encryptedLength = bytes[readIndex] * 256; +int encryptedLength = (bytes[readIndex] & 0xFF) << 8; readIndex++; -encryptedLength += bytes[readIndex]; +encryptedLength += (bytes[readIndex] & 0xFF);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.int encryptedLength = (bytes[readIndex] & 0xFF) << 8; readIndex++; encryptedLength += (bytes[readIndex] & 0xFF);app/src/org/commcare/android/database/connect/models/ConnectUserRecord.java (1)
185-191:
⚠️ Potential issueCheck for Null
verifySecondaryPhoneByDateIn
shouldRequireSecondaryPhoneVerification(), ensure thatverifySecondaryPhoneByDateis not null before comparing dates to avoid a potentialNullPointerException.Include a null check:
public boolean shouldRequireSecondaryPhoneVerification() { if (secondaryPhoneVerified) { return false; } + if (verifySecondaryPhoneByDate == null) { + // Handle null case appropriately, possibly requiring verification + return true; + } return (new Date()).after(verifySecondaryPhoneByDate); }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public boolean shouldRequireSecondaryPhoneVerification() { if(secondaryPhoneVerified) { return false; } if (verifySecondaryPhoneByDate == null) { // Handle null case appropriately, possibly requiring verification return true; } return (new Date()).after(verifySecondaryPhoneByDate); }app/src/org/commcare/connect/network/ApiConnectId.java (3)
37-38: 🛠️ Refactor suggestion
Avoid Using String Replacement for URL Construction
Using
replaceon URLs can be error-prone and hard to maintain. Instead, consider usingUri.Builderor manipulating the URL usingURLandURIclasses to construct the desired endpoint more reliably.Example:
try { URL keyServerUrl = new URL(ServerUrls.getKeyServer()); String baseUrl = keyServerUrl.getProtocol() + "://" + keyServerUrl.getHost(); String path = keyServerUrl.getPath().replace("/phone/keys/", "/settings/users/commcare/link_connectid_user/"); URL url = new URL(baseUrl + path); } catch (MalformedURLException e) { Logger.exception("Malformed URL", e); }
46-47:
⚠️ Potential issueEnsure Response Streams are Closed in All Cases
Currently, the
responseStreamis only closed whenresponseCode == 200. To prevent resource leaks, the stream should be closed regardless of the response code.Refactor the code to ensure the stream is closed:
if (postResult.e != null) { Logger.exception("Network error linking HQ worker", postResult.e); } else { try { if (postResult.responseCode == 200) { // Process successful response // Remember that we linked the user successfully appRecord.setWorkerLinked(true); ConnectDatabaseHelper.storeApp(context, appRecord); } else { Logger.log("API Error", "API call to link HQ worker failed with code " + postResult.responseCode); } } finally { if (postResult.responseStream != null) { postResult.responseStream.close(); } } }Committable suggestion skipped: line range outside the PR's diff.
60-96:
⚠️ Potential issueHandle Potential Null Pointer Exception in Token Retrieval
In
retrieveHqTokenApi, ifpostResult.responseStreamis null, callinginputStreamToByteArraymay cause aNullPointerException. Ensure the response stream is not null before processing.Add a null check:
if (postResult.responseCode == 200 && postResult.responseStream != null) { try { // Existing code } catch (IOException | JSONException e) { Logger.exception("Parsing return from HQ OIDC call", e); } }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public static AuthInfo.TokenAuth retrieveHqTokenApi(Context context, String hqUsername, String connectToken) { HashMap<String, String> params = new HashMap<>(); params.put("client_id", "4eHlQad1oasGZF0lPiycZIjyL0SY1zx7ZblA6SCV"); params.put("scope", "mobile_access sync"); params.put("grant_type", "password"); params.put("username", hqUsername + "@" + HiddenPreferences.getUserDomain()); params.put("password", connectToken); String url = ServerUrls.buildEndpoint("oauth/token/"); ConnectNetworkHelper.PostResult postResult = ConnectNetworkHelper.postSync(context, url, API_VERSION_NONE, new AuthInfo.NoAuth(), params, true, false); if (postResult.responseCode == 200 && postResult.responseStream != null) { try { String responseAsString = new String(StreamsUtil.inputStreamToByteArray( postResult.responseStream)); JSONObject json = new JSONObject(responseAsString); String key = ConnectConstants.CONNECT_KEY_TOKEN; if (json.has(key)) { String token = json.getString(key); Date expiration = new Date(); key = ConnectConstants.CONNECT_KEY_EXPIRES; int seconds = json.has(key) ? json.getInt(key) : 0; expiration.setTime(expiration.getTime() + ((long)seconds * 1000)); String seatedAppId = CommCareApplication.instance().getCurrentApp().getUniqueId(); ConnectDatabaseHelper.storeHqToken(context, seatedAppId, hqUsername, token, expiration); return new AuthInfo.TokenAuth(token); } } catch (IOException | JSONException e) { Logger.exception("Parsing return from HQ OIDC call", e); } } return null; }app/src/org/commcare/models/database/connect/ConnectDatabaseUpgrader.java (1)
287-311:
⚠️ Potential issueIncorrect Migration of
ConnectUserRecordin Upgrade Five to SixIn the
upgradeFiveSixmethod, botholdStorageandnewStorageare initialized withConnectUserRecordV5.class. This likely leads to data not being migrated correctly to the new version.Update
newStorageto use the newConnectUserRecordclass:SqlStorage<Persistable> oldStorage = new SqlStorage<>( ConnectUserRecord.STORAGE_KEY, ConnectUserRecordV5.class, new ConcreteAndroidDbHelper(c, db)); SqlStorage<Persistable> newStorage = new SqlStorage<>( ConnectUserRecord.STORAGE_KEY, - ConnectUserRecordV5.class, + ConnectUserRecord.class, new ConcreteAndroidDbHelper(c, db));📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.db.execSQL(DbUtil.addColumnToTable( ConnectUserRecord.STORAGE_KEY, ConnectUserRecord.META_PIN, "TEXT")); db.execSQL(DbUtil.addColumnToTable( ConnectUserRecord.STORAGE_KEY, ConnectUserRecord.META_SECONDARY_PHONE_VERIFIED, "TEXT")); db.execSQL(DbUtil.addColumnToTable( ConnectUserRecord.STORAGE_KEY, ConnectUserRecord.META_VERIFY_SECONDARY_PHONE_DATE, "TEXT")); SqlStorage<Persistable> oldStorage = new SqlStorage<>( ConnectUserRecord.STORAGE_KEY, ConnectUserRecordV5.class, new ConcreteAndroidDbHelper(c, db)); SqlStorage<Persistable> newStorage = new SqlStorage<>( ConnectUserRecord.STORAGE_KEY, ConnectUserRecord.class, new ConcreteAndroidDbHelper(c, db));app/src/org/commcare/connect/ConnectDatabaseHelper.java (2)
310-470: 🛠️ Refactor suggestion
Refactor the
storeJobsmethod to improve readabilityThe
storeJobsmethod spans over 160 lines and handles multiple operations including:
- Deleting old jobs and related records.
- Inserting or updating incoming jobs.
- Managing associated app info, learn modules, and payment units.
This makes the method difficult to read and maintain.
Consider breaking down the method into smaller helper methods, each handling a specific task:
deleteObsoleteJobsinsertOrUpdateJobsmanageAppInfomanageLearnModulesmanagePaymentUnitsRefactoring will make the code more modular, easier to test, and compliant with the Single Responsibility Principle.
77-80:
⚠️ Potential issueReplace generic
RuntimeExceptionwith specific exceptionsThrowing a generic
RuntimeExceptioncan obscure the original error and make debugging more challenging. In the catch blocks at lines 77-80, 109-111, and 127-129, you log the exception and then throw aRuntimeException.Consider rethrowing the caught exception or throwing a more specific exception that conveys meaningful information about the error.
- throw new RuntimeException(e); + throw e; // Re-throw the original exception to preserve stack traceOr define and throw a custom exception that provides context.
Also applies to: 109-111, 127-129
app/unit-tests/src/org/commcare/utils/MockEncryptionKeyProvider.java (1)
26-27:
⚠️ Potential issueCorrect the key usage for encryption and decryption
In the
getKeymethod, whentrueForEncryptistrue, you're returning the private key for encryption, and whenfalse, the public key for decryption. This is the opposite of standard RSA practices.In RSA encryption:
- Encryption uses the public key.
- Decryption uses the private key.
Swap the key retrieval to adhere to standard encryption practices.
Apply this diff to fix the key usage:
return new EncryptionKeyAndTransform( - trueForEncrypt ? keyPair.getPrivate() : keyPair.getPublic(), + trueForEncrypt ? keyPair.getPublic() : keyPair.getPrivate(), transformation);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.return new EncryptionKeyAndTransform(trueForEncrypt ? keyPair.getPublic() : keyPair.getPrivate(), transformation);app/unit-tests/src/org/commcare/utils/EncryptionUtilsTest.java (1)
23-29:
⚠️ Potential issueEnsure the test uses the correct keys after fixing key provider
After correcting the key usage in
MockEncryptionKeyProvider, update the test to use the correct keys:
- Use the public key for encryption.
- Use the private key for decryption.
Update the test code accordingly to reflect this change:
byte[] encrypted = EncryptionUtils.encrypt(testBytes, provider.getKey(null, true)); // Now uses public key byte[] decrypted = EncryptionUtils.decrypt(encrypted, provider.getKey(null, false)); // Now uses private keyVerify that the test passes after making these changes to ensure the encryption and decryption processes are functioning correctly.
app/src/org/commcare/preferences/ServerUrls.java (1)
37-44:
⚠️ Potential issueHandle potential null values and avoid throwing
RuntimeExceptionIn
buildEndpoint, ifgetKeyServer()returnsnull, creating aURLwill throw aMalformedURLException. Additionally, throwing a genericRuntimeExceptioncan make debugging difficult.Consider the following improvements:
- Check for null values before attempting to create a
URL.- Provide a meaningful exception or fallback mechanism.
- Log the exception to aid in troubleshooting.
Apply this diff to enhance error handling:
public static String buildEndpoint(String path) { try { String keyServerUrl = getKeyServer(); + if (keyServerUrl == null) { + throw new IllegalStateException("Key server URL is not set"); + } URL originalUrl = new URL(keyServerUrl); return new URL(originalUrl, path).toString(); } catch (MalformedURLException e) { + Logger.exception("Malformed URL in buildEndpoint: " + e.getMessage(), e); + throw new IllegalArgumentException("Invalid URL constructed in buildEndpoint", e); - throw new RuntimeException(e); } }Committable suggestion skipped: line range outside the PR's diff.
app/src/org/commcare/android/database/connect/models/ConnectUserRecordV5.java (2)
24-25:
⚠️ Potential issueConsider encrypting sensitive data
The
passwordfield should not be stored in plain text. Consider:
- Using a secure hashing algorithm (e.g., bcrypt, PBKDF2)
- Encrypting the field using Android's KeyStore system
Would you like me to provide an example implementation using Android's encryption utilities?
42-46: 🛠️ Refactor suggestion
Add token refresh mechanism
The
connectTokenandconnectTokenExpirationfields need a mechanism to handle token expiration and refresh. Consider:
- Adding a method to check token validity
- Implementing automatic token refresh
Example implementation:
+ public boolean isTokenValid() { + return connectToken != null && + connectTokenExpiration != null && + connectTokenExpiration.after(new Date()); + }Committable suggestion skipped: line range outside the PR's diff.
app/src/org/commcare/android/database/connect/models/ConnectPaymentUnitRecord.java (1)
48-50: 🛠️ Refactor suggestion
⚠️ Potential issueUse appropriate type for financial data
Using
intfor financial amounts can lead to precision issues. Consider usingBigDecimalfor monetary values to avoid floating-point arithmetic problems.- @Persisting(6) - @MetaField(META_AMOUNT) - private int amount; + @Persisting(6) + @MetaField(META_AMOUNT) + private BigDecimal amount;Committable suggestion skipped: line range outside the PR's diff.
app/src/org/commcare/android/database/connect/models/ConnectLearnModuleSummaryRecord.java (1)
63-66: 🛠️ Refactor suggestion
Improve null handling and validation
The
fromJsonmethod's null handling could be more explicit:
- Consider which fields should be required vs optional
- Validate timeEstimate bounds
- Add proper validation messages
- info.slug = json.has(META_SLUG) ? json.getString(META_SLUG) : null; - info.name = json.has(META_NAME) ? json.getString(META_NAME) : null; - info.description = json.has(META_DESCRIPTION) ? json.getString(META_DESCRIPTION) : null; - info.timeEstimate = json.has(META_ESTIMATE) ? json.getInt(META_ESTIMATE) : -1; + // Required fields + if (!json.has(META_SLUG) || !json.has(META_NAME)) { + throw new IllegalArgumentException("Missing required fields: slug and name"); + } + info.slug = json.getString(META_SLUG); + info.name = json.getString(META_NAME); + + // Optional fields + info.description = json.optString(META_DESCRIPTION, null); + info.timeEstimate = json.optInt(META_ESTIMATE, 0); + + // Validate timeEstimate + if (info.timeEstimate < 0) { + throw new IllegalArgumentException("Time estimate cannot be negative"); + }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.// Required fields if (!json.has(META_SLUG) || !json.has(META_NAME)) { throw new IllegalArgumentException("Missing required fields: slug and name"); } info.slug = json.getString(META_SLUG); info.name = json.getString(META_NAME); // Optional fields info.description = json.optString(META_DESCRIPTION, null); info.timeEstimate = json.optInt(META_ESTIMATE, 0); // Validate timeEstimate if (info.timeEstimate < 0) { throw new IllegalArgumentException("Time estimate cannot be negative"); }app/src/org/commcare/android/database/connect/models/ConnectLinkedAppRecord.java (4)
39-40:
⚠️ Potential issueConsider adding password validation and encryption.
The password field is stored as a plain string and lacks validation. This could pose security risks.
Consider:
- Encrypting the password before storage
- Adding password validation
- Using a secure password type instead of String
- @Persisting(3) - private String password; + @Persisting(3) + private SecureString password; - public void setPassword(String password) { - this.password = password; + public void setPassword(String password) { + validatePassword(password); + this.password = new SecureString(encryptPassword(password)); + }Also applies to: 94-96
156-174:
⚠️ Potential issueAdd null checks in fromV9 migration method.
The
fromV9method assumes all getters fromoldRecordreturn non-null values.public static ConnectLinkedAppRecord fromV9(ConnectLinkedAppRecordV9 oldRecord) { + if (oldRecord == null) { + throw new IllegalArgumentException("oldRecord cannot be null"); + } ConnectLinkedAppRecord newRecord = new ConnectLinkedAppRecord(); - newRecord.appId = oldRecord.getAppId(); - newRecord.userId = oldRecord.getUserId(); + String appId = oldRecord.getAppId(); + String userId = oldRecord.getUserId(); + if (appId == null || userId == null) { + throw new IllegalStateException("Required fields appId and userId cannot be null"); + } + newRecord.appId = appId; + newRecord.userId = userId;Committable suggestion skipped: line range outside the PR's diff.
44-45: 🛠️ Refactor suggestion
Add expiration time validation.
The
hqTokenExpirationfield should be validated to ensure it's set to a future date.- public void updateHqToken(String token, Date expirationDate) { - hqToken = token; - hqTokenExpiration = expirationDate; + public void updateHqToken(String token, Date expirationDate) { + if (expirationDate.before(new Date())) { + throw new IllegalArgumentException("Token expiration must be in the future"); + } + hqToken = token; + hqTokenExpiration = expirationDate; + }Committable suggestion skipped: line range outside the PR's diff.
127-132: 🛠️ Refactor suggestion
Add audit logging for security-sensitive operations.
The
severConnectIdLinkmethod performs security-sensitive operations without logging.public void severConnectIdLink() { + DataChangeLogger.log(DataChangeLogger.Category.SECURITY, + "Severing ConnectID link for user: " + userId); connectIdLinked = false; password = ""; linkOffered1 = false; linkOffered2 = false; }Committable suggestion skipped: line range outside the PR's diff.
app/src/org/commcare/CommCareApplication.java (2)
307-312: 🛠️ Refactor suggestion
Consider thread safety for background sync methods
The backgroundSyncSafe flag is accessed from multiple methods but lacks synchronization. Consider adding synchronized keyword to prevent race conditions.
- public void setBackgroundSyncSafe(boolean backgroundSyncSafe) { + public synchronized void setBackgroundSyncSafe(boolean backgroundSyncSafe) { this.backgroundSyncSafe = backgroundSyncSafe; } - public boolean isBackgroundSyncSafe() { + public synchronized boolean isBackgroundSyncSafe() { return this.backgroundSyncSafe; }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public synchronized void setBackgroundSyncSafe(boolean backgroundSyncSafe) { this.backgroundSyncSafe = backgroundSyncSafe; } public synchronized boolean isBackgroundSyncSafe() { return this.backgroundSyncSafe;
1163-1169: 🛠️ Refactor suggestion
Consider thread safety for encryption provider methods
The encryption provider getter/setter methods should be synchronized to ensure thread-safe access to this critical security component.
- public void setEncryptionKeyProvider(EncryptionKeyProvider provider) { + public synchronized void setEncryptionKeyProvider(EncryptionKeyProvider provider) { encryptionKeyProvider = provider; } - public EncryptionKeyProvider getEncryptionKeyProvider() { + public synchronized EncryptionKeyProvider getEncryptionKeyProvider() { return encryptionKeyProvider; }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public synchronized void setEncryptionKeyProvider(EncryptionKeyProvider provider) { encryptionKeyProvider = provider; } public synchronized EncryptionKeyProvider getEncryptionKeyProvider() { return encryptionKeyProvider; }app/src/org/commcare/android/database/connect/models/ConnectLinkedAppRecordV8.java (2)
88-94:
⚠️ Potential issuePotential null pointer dereference in getLinkOfferDate methods
The methods return null when linkOffered is false, but there's no null check for the date fields themselves.
- public Date getLinkOfferDate1() { - return linkOffered1 ? linkOfferDate1 : null; - } + public Date getLinkOfferDate1() { + return (linkOffered1 && linkOfferDate1 != null) ? linkOfferDate1 : null; + } - public Date getLinkOfferDate2() { - return linkOffered2 ? linkOfferDate2 : null; - } + public Date getLinkOfferDate2() { + return (linkOffered2 && linkOfferDate2 != null) ? linkOfferDate2 : null; + }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public Date getLinkOfferDate1() { return (linkOffered1 && linkOfferDate1 != null) ? linkOfferDate1 : null; } public Date getLinkOfferDate2() { return (linkOffered2 && linkOfferDate2 != null) ? linkOfferDate2 : null; }
96-113: 🛠️ Refactor suggestion
Improve version migration safety and documentation
The fromV3 method makes assumptions about the state of the new record without proper documentation or validation.
- Add method documentation explaining the migration strategy
- Validate oldRecord is not null
- Consider making linkOfferDate2 null instead of current date when linkOffered2 is false
+ /** + * Migrates a V3 record to V8 format. + * Sets default values for new fields: + * - connectIdLinked: true (assuming V3 records were all connected) + * - linkOffered1: true with current date + * - linkOffered2: false with null date + * + * @param oldRecord The V3 record to migrate + * @return A new V8 record + * @throws IllegalArgumentException if oldRecord is null + */ public static ConnectLinkedAppRecordV8 fromV3(ConnectLinkedAppRecordV3 oldRecord) { + if (oldRecord == null) { + throw new IllegalArgumentException("Cannot migrate null record"); + } ConnectLinkedAppRecordV8 newRecord = new ConnectLinkedAppRecordV8(); newRecord.appId = oldRecord.getAppId(); newRecord.userId = oldRecord.getUserId(); newRecord.password = oldRecord.getPassword(); newRecord.workerLinked = oldRecord.getWorkerLinked(); newRecord.hqToken = oldRecord.getHqToken(); newRecord.hqTokenExpiration = oldRecord.getHqTokenExpiration(); newRecord.connectIdLinked = true; newRecord.linkOffered1 = true; newRecord.linkOfferDate1 = new Date(); newRecord.linkOffered2 = false; - newRecord.linkOfferDate2 = new Date(); + newRecord.linkOfferDate2 = null; return newRecord; }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements./** * Migrates a V3 record to V8 format. * Sets default values for new fields: * - connectIdLinked: true (assuming V3 records were all connected) * - linkOffered1: true with current date * - linkOffered2: false with null date * * @param oldRecord The V3 record to migrate * @return A new V8 record * @throws IllegalArgumentException if oldRecord is null */ public static ConnectLinkedAppRecordV8 fromV3(ConnectLinkedAppRecordV3 oldRecord) { if (oldRecord == null) { throw new IllegalArgumentException("Cannot migrate null record"); } ConnectLinkedAppRecordV8 newRecord = new ConnectLinkedAppRecordV8(); newRecord.appId = oldRecord.getAppId(); newRecord.userId = oldRecord.getUserId(); newRecord.password = oldRecord.getPassword(); newRecord.workerLinked = oldRecord.getWorkerLinked(); newRecord.hqToken = oldRecord.getHqToken(); newRecord.hqTokenExpiration = oldRecord.getHqTokenExpiration(); newRecord.connectIdLinked = true; newRecord.linkOffered1 = true; newRecord.linkOfferDate1 = new Date(); newRecord.linkOffered2 = false; newRecord.linkOfferDate2 = null; return newRecord; }app/src/org/commcare/android/database/connect/models/ConnectAppRecord.java (2)
63-63:
⚠️ Potential issueAdd @persisting annotation for learnModules
The learnModules field should be persisted to maintain data consistency.
+ @Persisting(11) private List<ConnectLearnModuleSummaryRecord> learnModules;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.@Persisting(11) private List<ConnectLearnModuleSummaryRecord> learnModules;
83-88:
⚠️ Potential issueImprove error handling in JSON array processing
The code assumes META_MODULES exists and is an array, which could throw JSONException.
- JSONArray array = json.getJSONArray(META_MODULES); - app.learnModules = new ArrayList<>(); - for(int i=0; i<array.length(); i++) { - JSONObject obj = (JSONObject)array.get(i); - app.learnModules.add(ConnectLearnModuleSummaryRecord.fromJson(obj, i)); - } + app.learnModules = new ArrayList<>(); + if (json.has(META_MODULES) && !json.isNull(META_MODULES)) { + JSONArray array = json.getJSONArray(META_MODULES); + for(int i = 0; i < array.length(); i++) { + Object item = array.get(i); + if (item instanceof JSONObject) { + app.learnModules.add(ConnectLearnModuleSummaryRecord.fromJson((JSONObject)item, i)); + } + } + }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.app.learnModules = new ArrayList<>(); if (json.has(META_MODULES) && !json.isNull(META_MODULES)) { JSONArray array = json.getJSONArray(META_MODULES); for(int i = 0; i < array.length(); i++) { Object item = array.get(i); if (item instanceof JSONObject) { app.learnModules.add(ConnectLearnModuleSummaryRecord.fromJson((JSONObject)item, i)); } } }app/src/org/commcare/android/database/connect/models/ConnectJobPaymentRecord.java (3)
99-107: 🛠️ Refactor suggestion
Improve payment confirmation window logic
The allowConfirm method has potential issues:
- No null check for date field
- Magic number "7" should be a constant
- Time calculation could be more precise
+ private static final int CONFIRMATION_WINDOW_DAYS = 7; + public boolean allowConfirm() { if (confirmed) { return false; } + if (date == null) { + return false; + } long millis = (new Date()).getTime() - date.getTime(); long days = TimeUnit.DAYS.convert(millis, TimeUnit.MILLISECONDS); - return days < 7; + return days < CONFIRMATION_WINDOW_DAYS; }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.private static final int CONFIRMATION_WINDOW_DAYS = 7; public boolean allowConfirm() { if (confirmed) { return false; } if (date == null) { return false; } long millis = (new Date()).getTime() - date.getTime(); long days = TimeUnit.DAYS.convert(millis, TimeUnit.MILLISECONDS); return days < CONFIRMATION_WINDOW_DAYS; }
63-66:
⚠️ Potential issueImprove default values in fromV3 migration
The migration sets potentially problematic default values:
- paymentId of "-1" is not a meaningful default
- Setting confirmedDate when confirmed is false is inconsistent
- newRecord.paymentId = "-1"; + newRecord.paymentId = ""; newRecord.confirmed = false; - newRecord.confirmedDate = new Date(); + newRecord.confirmedDate = null;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.newRecord.paymentId = ""; newRecord.confirmed = false; newRecord.confirmedDate = null;
75-75: 🛠️ Refactor suggestion
Avoid string formatting for numeric amount
Using string formatting for a numeric amount could lead to localization issues and makes arithmetic operations harder.
- payment.amount = String.format(Locale.ENGLISH, "%d", json.has(META_AMOUNT) ? json.getInt(META_AMOUNT) : 0); + payment.amount = String.valueOf(json.has(META_AMOUNT) ? json.getInt(META_AMOUNT) : 0);Consider changing the
amountfield type tointorBigDecimalfor better numeric handling.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.payment.amount = String.valueOf(json.has(META_AMOUNT) ? json.getInt(META_AMOUNT) : 0);
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (2)
app/src/org/commcare/android/database/connect/models/ConnectUserRecord.java (1)
68-74: Review initialization ofconnectTokenExpiration.Initializing
connectTokenExpirationtonew Date()may causegetConnectToken()to always returnnulluntilupdateConnectToken()is called. Consider setting it tonullor a default value indicating no token by default.app/src/org/commcare/connect/network/SsoToken.java (1)
28-29: Handle missing access token more gracefully.Throwing a
RuntimeExceptionwhen the access token is missing may not provide sufficient error context. Consider throwing a custom exception or returning an error object to handle this scenario more effectively.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
app/src/org/commcare/android/database/connect/models/ConnectLinkedAppRecord.java(1 hunks)app/src/org/commcare/android/database/connect/models/ConnectUserRecord.java(1 hunks)app/src/org/commcare/connect/ConnectDatabaseHelper.java(1 hunks)app/src/org/commcare/connect/network/ApiConnectId.java(1 hunks)app/src/org/commcare/connect/network/SsoToken.java(1 hunks)
🔇 Additional comments (2)
app/src/org/commcare/connect/network/ApiConnectId.java (1)
38-39: Use ServerUrls.buildEndpoint instead of string replacement.
Instead of manipulating URLs using string replacement, consider using ServerUrls.buildEndpoint to construct the endpoint URL for better reliability and maintainability.
app/src/org/commcare/connect/ConnectDatabaseHelper.java (1)
45-45: 🛠️ Refactor suggestion
Consider splitting ConnectDatabaseHelper into smaller helper classes.
Separating CRUD logic for different models into dedicated helper classes would enhance code organization and maintainability.
| private String password; | ||
|
|
There was a problem hiding this comment.
Ensure secure storage of passwords.
Storing passwords in plain text can lead to security vulnerabilities. Consider encrypting or hashing the password field before persisting it.
|
|
||
| public static AuthInfo.TokenAuth retrieveHqTokenApi(Context context, String hqUsername, String connectToken) { | ||
| HashMap<String, String> params = new HashMap<>(); | ||
| params.put("client_id", "4eHlQad1oasGZF0lPiycZIjyL0SY1zx7ZblA6SCV"); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Avoid hardcoding client IDs in the code.
Storing client_id values directly in the code can pose security risks and reduces flexibility. Consider moving them to a secure configuration file or defining them as constants.
Also applies to: 112-112
| } | ||
|
|
||
| //Now insert/update the job | ||
| jobStorage.write(incomingJob); | ||
|
|
||
| //Next, store the learn and delivery app info | ||
| incomingJob.getLearnAppInfo().setJobId(incomingJob.getJobId()); | ||
| incomingJob.getDeliveryAppInfo().setJobId(incomingJob.getJobId()); | ||
| Vector<ConnectAppRecord> records = appInfoStorage.getRecordsForValues( | ||
| new String[]{ConnectAppRecord.META_JOB_ID}, | ||
| new Object[]{incomingJob.getJobId()}); | ||
|
|
||
| for (ConnectAppRecord existing : records) { | ||
| ConnectAppRecord incomingAppInfo = existing.getIsLearning() ? incomingJob.getLearnAppInfo() : incomingJob.getDeliveryAppInfo(); | ||
| incomingAppInfo.setID(existing.getID()); | ||
| } | ||
|
|
||
| incomingJob.getLearnAppInfo().setLastUpdate(new Date()); | ||
| appInfoStorage.write(incomingJob.getLearnAppInfo()); | ||
|
|
||
| incomingJob.getDeliveryAppInfo().setLastUpdate(new Date()); | ||
| appInfoStorage.write(incomingJob.getDeliveryAppInfo()); | ||
|
|
||
| //Store the info for the learn modules | ||
| //Delete modules that are no longer available | ||
| Vector<Integer> foundIndexes = new Vector<>(); | ||
| //Note: Reusing this vector | ||
| moduleIdsToDelete.clear(); | ||
| Vector<ConnectLearnModuleSummaryRecord> existingLearnModules = | ||
| moduleStorage.getRecordsForValues( | ||
| new String[]{ConnectLearnModuleSummaryRecord.META_JOB_ID}, | ||
| new Object[]{incomingJob.getJobId()}); | ||
| for (ConnectLearnModuleSummaryRecord existing : existingLearnModules) { | ||
| boolean stillExists = false; | ||
| if (!foundIndexes.contains(existing.getModuleIndex())) { | ||
| for (ConnectLearnModuleSummaryRecord incoming : | ||
| incomingJob.getLearnAppInfo().getLearnModules()) { | ||
| if (Objects.equals(existing.getModuleIndex(), incoming.getModuleIndex())) { | ||
| incoming.setID(existing.getID()); | ||
| stillExists = true; | ||
| foundIndexes.add(existing.getModuleIndex()); | ||
|
|
||
| break; | ||
| } | ||
| } | ||
| } | ||
|
|
||
| if (!stillExists) { | ||
| moduleIdsToDelete.add(existing.getID()); | ||
| } | ||
| } | ||
|
|
||
| moduleStorage.removeAll(moduleIdsToDelete); | ||
|
|
||
| for (ConnectLearnModuleSummaryRecord module : incomingJob.getLearnAppInfo().getLearnModules()) { | ||
| module.setJobId(incomingJob.getJobId()); | ||
| module.setLastUpdate(new Date()); | ||
| moduleStorage.write(module); | ||
| } | ||
|
|
||
|
|
||
| //Store the payment units | ||
| //Delete payment units that are no longer available | ||
| foundIndexes = new Vector<>(); | ||
| //Note: Reusing this vector | ||
| paymentUnitIdsToDelete.clear(); | ||
| Vector<ConnectPaymentUnitRecord> existingPaymentUnits = | ||
| paymentUnitStorage.getRecordsForValues( | ||
| new String[]{ConnectPaymentUnitRecord.META_JOB_ID}, | ||
| new Object[]{incomingJob.getJobId()}); | ||
| for (ConnectPaymentUnitRecord existing : existingPaymentUnits) { | ||
| boolean stillExists = false; | ||
| if (!foundIndexes.contains(existing.getUnitId())) { | ||
| for (ConnectPaymentUnitRecord incoming : | ||
| incomingJob.getPaymentUnits()) { | ||
| if (Objects.equals(existing.getUnitId(), incoming.getUnitId())) { | ||
| incoming.setID(existing.getID()); | ||
| stillExists = true; | ||
| foundIndexes.add(existing.getUnitId()); | ||
|
|
||
| break; | ||
| } | ||
| } | ||
| } | ||
|
|
||
| if (!stillExists) { | ||
| paymentUnitIdsToDelete.add(existing.getID()); | ||
| } | ||
| } | ||
|
|
||
| paymentUnitStorage.removeAll(paymentUnitIdsToDelete); | ||
|
|
||
| for (ConnectPaymentUnitRecord record : incomingJob.getPaymentUnits()) { | ||
| record.setJobId(incomingJob.getJobId()); | ||
| paymentUnitStorage.write(record); | ||
| } | ||
| } | ||
|
|
||
| return newJobs; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Refactor storeJobs method for better maintainability.
The storeJobs method is quite lengthy and handles multiple responsibilities. Breaking it down into smaller, well-named methods would improve readability and simplify future maintenance.
| private String password; | ||
| @Persisting(4) |
There was a problem hiding this comment.
Ensure secure storage of passwords.
Storing passwords in plain text can lead to security vulnerabilities. Consider encrypting or hashing the password field before persisting it.
…ing DateUtils functions instead.
…sed in both sync and async POST functions.
Summary
Foundational code for ConnectID, primarily consisting of database, network, and encryption code.
This code will support ConnectID when it is integrated into the codebase.
Currently the code in this PR is compiled, but almost completely uncalled.
Product Description
Safety Assurance
The code in this PR is currently not called from anywhere, except:
The EncryptionKeyProvider is created and stored, but never used
Automated test coverage
Unit tests created for the encryption code