I created a signed pdf using iText7 with an EC key. The PDF is verified successfully in Adobe Acrobat reader without complaint. However, when checked with ETSI conformance checker, the tool complains 'Unknown signature type requested: SHA256With1.2.840.10045.2.1'
The SignatureAlgorithmIdentifier in the Cryptographic Messaging Syntax (CMS) is shown as ecPublicKey instead of an ECDSA with SHA256
SEQUENCE (2 elem)
OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key type)
NULL
Checking the iText7 source code shows that PdfPKCS7 uses SecurityIDs which defines ECDSA OID as the following:
public static final String ID_ECDSA = "1.2.840.10045.2.1";
May I know if this is a bug where the code should be changed to use the following ECDSA signature algorithm OIDs?
public static final String ID_ECDSA_SHA224 = "1.2.840.10045.4.3.1";
public static final String ID_ECDSA_SHA256 = "1.2.840.10045.4.3.2";
public static final String ID_ECDSA_SHA384 = "1.2.840.10045.4.3.3";
public static final String ID_ECDSA_SHA512 = "1.2.840.10045.4.3.4";
Thank you.
Related
WatchFaceService has a method public void onPropertiesChanged(Bundle properties) which returns a bundle of properties. One of them has a key PROPERTY_OFFLOAD_SUPPORTED.
Here are all properties that are available in WatchFaceService:
public static final String PROPERTY_BURN_IN_PROTECTION = "burn_in_protection";
public static final String PROPERTY_LOW_BIT_AMBIENT = "low_bit_ambient";
public static final String PROPERTY_IN_RETAIL_MODE = "in_retail_mode";
public static final String PROPERTY_OFFLOAD_SUPPORTED = "offload_supported";
public static final String PROPERTY_PHYSICAL_HANDS = "physical_hands";
They are not there in the docs but can be accessed from Android Studio.
What does PROPERTY_OFFLOAD_SUPPORTED property represent, and how it should be used?
PROPERTY_OFFLOAD_SUPPORTED is related to WatchFaceDecomposition. This is a feature that's available on certain devices (built on the Qualcomm 3100 platform), where the ambient mode drawing of the watch face is handed over to a separate (very energy-efficient) piece of hardware.
There are a lot of restrictions for what you can and can't do in this mode. It also offers a few new opportunities such as more color options and having a second hand(!).
The feature is unfortunately not very well-documented but there are a few articles out there that talk about how to build watch faces that supports it:
http://turndapage.com/2018/12/07/implementing-the-new-ambient-second-hand-for-wear-os-with-watch-face-decompositions
https://www.programmersought.com/article/49454594831/
I want to use UUID as an identifier but standard scalar ID is coerced as string.
So have to parse uuid from string everywhere I use ID type.
I wonder is it possible to override ID type with my own implementation?
This scalar type has some special meaning or I can just use my own scalar called UUID as identifier?
We can not override the available scalers, please refer this link for discussion.
You can define a UUIDScalar in your code, for the same you will have to override the following methods
#Override
public Object serialize(Object dataFetcherResult) {
//
}
#Override
public Object parseValue(Object input) {
//
}
#Override
public Object parseLiteral(Object input) {
//
}
Reference: Making custom scalars in graphql java
Luckily the code for making custom scalar for UUID is available online, you can use this PR
I've got ODM 8.9.1 Rule Designer running on a Java 8 vm. Java.time.* types show up in the XOM but are not recognized in the BOM. For example, a java.time.LocalDate shows "cannot be verbalized" and cannot be found in the Ctrl-Shift-Space verbal completion choices.
I've got my XOM on Java 8. How do I get my BOM to Java 8?
One way to get your BOM using Java 8 dates is to create a helper method in your XOM that takes the verbalized java.util.Date and convert this to a java.time.LocalDateTime For example,
public static int compareDates(Date date1, Date date2) {
LocalDateTime newDate1 = date1.toInstant().atZone(ZoneId.systemDefault()).toLocalDateTime();
LocalDateTime newDate2 = date2.toInstant().atZone(ZoneId.systemDefault()).toLocalDateTime() ;
return newDate1.compareTo(newDate2);
}
While ODM 8.10 has been available for some time and includes native support for the java.time package, I am stuck using ODM 8.9.1 for a while longer. Here is how I was able to use java.time.LocalDate and java.time.ZonedDateTime in my ODM 8.9.1 Rule Apps.
I manually created a new BOM Entry in my BOM project and manually added the java.time.LocalDate and java.time.ZonedDateTime classes with no members. I am able to verbalize LocalDate, but not ZonedDateTime. Rule Designer reports no errors or warnings, and I am able to build and execute just fine. As long as I stay away from BOM Update, defining these classes in the BOM works fine.
I have custom classes with data members of type ZonedDateTime. These are in a separate BOM Entry from the java time classes. I can verbalize those members and use them as expected with my custom methods, which accept parameters and return values of type ZonedDateTime.
Here is the glitch: Those ZonedDateTime members show up in the Vocabulary view as being of System type 'date' and are proposed in the Intellirule editor for the System 'date' operations. As expected, using one of these operations in a rule produces an error, but the error is visible only in the ARL tap, and not in the Intellirule tab or the Problems view.
I'm not sure how or why RD determined that those members are of type 'date'. I'm hoping to find a way to turn off the System verbalizations related to 'date'. Meanwhile, I just avoid using the System 'date' operations and my Rule Apps execute just fine. And when we do finally switch to ODM 8.10, I'll be ready to go.
Now, about HTDS and REST and JSON. The Swagger for java.util.Date uses the format "date-time". The Swagger for java.time.ZonedDateTime also uses "date-time", while for java.time.LocalDate it uses "date". So java.time.ZonedDateTime is a direct replacement for java.util.Date without affecting the calling apps. But you must use a custom deserializer to make it work, which involves a couple steps:
In the class where you define you data member, you must use an annotation:
#JsonDeserialize(using = CustomZonedDateTimeDeserializer.class)
private ZonedDateTime yourDateMember;
And you must define a that custom deserializer class:
#NotBusiness
public class CustomZonedDateTimeDeserializer extends StdDeserializer<ZonedDateTime> {
private static final long serialVersionUID = -3569126727040924932L;
public CustomZonedDateTimeDeserializer() {
this(null);
}
public CustomZonedDateTimeDeserializer(final Class<?> vc) {
super(vc);
}
#Override
public ZonedDateTime deserialize(final JsonParser jsonparser, final DeserializationContext context) throws IOException {
final String dateStr = jsonparser.getText();
try {
return ZonedDateTime.parse(dateStr);
} catch (final Exception e) {
return null; // Parsing of the date failed, continue processing of the request with null value for the date
}
}
}
I was hoping following might work:
#Size(min = 1, message = "{my.custom.message}")
private String name;
with ValidationMessages.properties in my source path, alogn with my other text resources:
my.custom.message=it is kinda short
...yet the constraint violation still reads {my.custom.message}
Does one have to do something special to have the ValidationMessages.properties file picked up? And where is this documented please?
Apparently it should work, somehow: https://github.com/gwtproject/gwt/issues/5762
Thanks to TBroyer's reply I managed to make it work in my project.
In a nutshell...
...define MyCustomValidationMessages interface:
public interface MyCustomValidationMessages extends com.google.gwt.i18n.client.ConstantsWithLookup {
#DefaultStringValue("NotNull constraint violated")
#Key("notNull")
String notNull();
#DefaultStringValue("Size constraint violated")
#Key("size")
String size();
}
...create MyCustomValidationMessages.properties right next to it:
notNull=must not be null
size=must be at least {min} characters long
...define MyCustomValidationMessagesResolver class and make it use messages from MyCustomValidationMessages interface:
public class MyCustomValidationMessagesResolver extends AbstractValidationMessageResolver
implements UserValidationMessagesResolver {
public MyCustomValidationMessagesResolver() {
super(GWT.create(MyCustomValidationMessages.class));
}
}
...in your AmazingModule.gwt.xml override use of UserValidationMessagesResolver with MyCustomValidationMessagesResolver:
<replace-with class="amazing.project.client.MyCustomValidationMessagesResolver">
<when-type-is class="com.google.gwt.validation.client.UserValidationMessagesResolver"/>
</replace-with>
...apply the constraints in your DTO bean (note the curly brackets):
public class MyDto {
#NotNull(message = "{notNull}")
#Size(min = 1, message = "{size}")
private String name;
}
Voilá!
Working example is here.
If you are sure you have done everything and it just does not work try deleting GWT's temp folders and restarting your IDE. Sometimes merely rebuilding your project and restarting the codeserver (in Idea) might not be enough. #PITA
I'm working on a project using Spring 3.1. We're doing all our validation server side but are running into an issue when a request parameter is bound to a Long or Integer object. While most invalid values ultimately result in an exception and an error message is displayed, this is not the case when the request parameter contains whitespace between digits. For example, when binding "12345 6789", we would expect a validation error but instead the whitespace is just getting trimmed out.
I've used the debugger to find that this is occurring in org.springframework.util.NumberUtils. A StringUtils.trimAllWhitespace is called to remove the whitespace from all input. This seems like a common enough use-case but I've so far been unable to find anyone who has a good solution. What would be the best way to do a simple conversion of the String on the request parameters to Long or Integer while only accepting digits?
A solution would be to create a custom validator that will meet your needs.
Example taken from the documentation:
Constraint declaration:
#Target({ElementType.METHOD, ElementType.FIELD})
#Retention(RetentionPolicy.RUNTIME)
#Constraint(validatedBy=MyConstraintValidator.class)
public #interface MyConstraint {
}
Constraint implementation
import javax.validation.ConstraintValidator;
public class MyConstraintValidator implements ConstraintValidator {
#Autowired;
private Foo aDependency;
...
}
Edit:
Creating a custom property converter documentation.
#Controller
public class MyFormController {
#InitBinder
public void initBinder(WebDataBinder binder) {
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");
dateFormat.setLenient(false);
binder.registerCustomEditor(Date.class, new CustomDateEditor(dateFormat, false));
}
// ...
}