Precondition: service based on CXF receives request/response with data, which violates XSD restriction.
Actual behavior:
In this case CXF returns fault with message like:
cvc-maxLength-valid: Value 'string_length_violated_value' with length = '28' is not facet-valid with respect to maxLength '13' for type 'XSDStringTypeWithLengthRestriction'
Goal:
return fault to consumer with name of field which contains invalid data. F.e. something like this:
Response from provider contains invalid data. Value 'string_length_violated_value' of field 'field_name' is not facet-valid with respect to maxLength '13'.
I'm wondering if it is possible and if so, then how to determine (where to retrieve from) this field name?
I'm not sure if this will completely work, but you can give it a try:
You can create a JAXB ValidationEventHandler and register that on your endpoint.
The ValidationEvent that it gets has the basic string (that you see above) and other information. I would put a breakpoint in there and dig into the event to see if ANY additional and useful information is available.
Related
I'm new to perfecto mobile device automation. I came across a name field which returns value in two lines in the application. Like below
School Name : ABCD
INTERNATIONAL
I found the locator which is Xpath as //*[text()="ABCD INTERNATIONAL"], this returns value in two lines which I confirmed when I ran the code and asserted the value. So basically the error is like below
expected [ABCD INTERNATIONAL] but found [ABCD
INTERNATIONAL]
My feature file is like
Feature: Verify the school Details
Scenario : Verify the school Name
Given User logs into Application
When User verifies the school name as "ABCD INTERNATIONAL"
Then user logs of
Step Defenition:
#When("User verifies the school name as {string}")
public void a_User_verifies_the_school_name_as (String Name) throws Exception {
String School_Name = utility.getText(appiumDriver, "//*[text()="ABCD INTERNATIONAL"]);
Assert.assertEquals(School_Name, Name);
}
Your help in sorting out this will mean a lot.
I think you have to modify your actual and expected string by using replaceAll() method.
Like replaceAll("\n",""); and replaceAll(" ",""). then compare both in assertion.
If it is not working then you have to use pattern matching by regular expression.
I am using a following code to compare 2 strings in one of protractor/jasmine test cases.
emailnotsentmessage.getText().then(function(text) {
expect(text).toBe('has not received notification about recent changes to the meeting.');
});
where emailnotsentmessage contains following text
[ 'has not received notification about recent changes to the meeting.' ]
for some reason , the string comparison fails . those two strings contains absolute same content. i checked it several times . am i missing something here ?. the emailnotsentmessage is a content of a <span> .
error trace
1) Get to the existing meeting by navigating to the edit meeting page should display the same value which was entered du
ring create meeting when go into edit meeting
Message:
Expected [ 'has not received notification about recent changes to the meeting.' ] to equal 'has not received notific
ation about recent changes to the meeting.'.
Stack:
Error: Failed expectation
Looks like your emailnotsentmessage is array and not a string. What if you try expect(text).toBe(['has not received notification about recent changes to the meeting.']); or maybe emailnotsentmessage[0]
found a fix and the reason behind this issue
i was earlier using var emailnotsentmessage = element.all(by.css('css path')); to get the element which caused the problem . It returns the string in an array format . instead i used the element(by.css('css path')); and it returns the expected string value .
I'm using the rabbitmq-c library to connect to a RabbitMQ server (GNU/Linux build environment).
At one point when I use "amqp_channel_open(...)", I'm getting an error from the server which I want to debug.
I call "amqp_get_rpc_reply(...)" as per the examples. It returns an amqp_rpc_reply_t which I assign to a variable "my_reply".
my_reply.reply_type is AMQP_RESPONSE_SERVER_EXCEPTION, which is why I think it's an error from the server.
HOWEVER, here are the docs for the amqp_rpc_reply_t type.
For my_reply.reply: "in case of AMQP_RESPONSE_SERVER_EXCEPTION this field will be set to the method returned from the broker"
So my_reply.reply is an amqp_method_t in this case. But when I look at the docs for amqp_method_t, it has two fields: id ("the method id number", ??) and decoded.
For decoded, it's a void *:
"pointer to the decoded method, cast to the appropriate type to use"
I am stuck at this point, because I have no idea what to cast **decoded* to. It should be some kind of data structure containing the information returned by the server (the AMQP method), but I can't find any reference to what type I should cast it to.
[Edited for clarity]
I dug around a bit in the examples, and found something helpful.
When my_reply.reply_type is AMQP_RESPONSE_SERVER_EXCEPTION, the field my_reply.reply.id contains one of the AMQP_xxxxxx_METHOD constants which are defined by macros in amqp_framing.h - see here and scroll down a bit.
Each of these method IDs has an associated type which follows the same naming convention - e.g. for AMQP_CONNECTION_CLOSE_METHOD (which I was getting) there is amqp_connection_close_t. See here for a list of data structures / types.
Knowing which type to cast my_reply.reply.decoded to, it's pretty easy to then extract the useful information - e.g. (from examples, assuming my_reply.reply.id is AMQP_CONNECTION_CLOSE_METHOD):
amqp_connection_close_t *m = (amqp_connection_close_t *)my_reply.reply.decoded;
printf( "Server connection error %d, message: %.*s\n",
m->reply_code,
(int) m->reply_text.len,
(char *) m->reply_text.bytes);
Usually AD returns 'Objectsid' as a byte[]. So I type cast the value returned by AD in to byte[]. This procedure worked against several AD but not in one case. In this AD environment, I get following exception.
Exception: Unable to cast object of type 'System.String' to type 'System.Byte[]'. (System.InvalidCastException)
To debug this I started checking data-type of the value returned by AD, and it was system.string not byte[]. I printed this string and it was garbage. Then I passed this string to SecurityIdentifier() and I got exception again.
Exception: Value was invalid. Parameter name: sddlForm (System.ArgumentException)
Code:
//Using System.DirectoryServices.Protocols objects
object s = objSrEc[k1].Attributes[(string)obj3.Current][0];
string x = s.GetType().FullName;
if (x.ToLower() == "system.byte[]")
{
byte[] bSID = ((byte[])s);
if (bSID != null)
{
SecurityIdentifier SID = new SecurityIdentifier(bSID, 0);
String ObjectSID = SID.Value;
}
}
else if (x.ToLower() == "system.string")
{
SecurityIdentifier SID = new SecurityIdentifier((String)s); //ssdl excception
String ObjectSID = SID.Value;
}
This is the first time I am seeing AD return string data for ObjectSID. I have run my code against many AD servers. I am planning to check the data-type of ObjectSID in AD schema.
Do any one come across this behavior? Should I call the Win32 api ConvertByteToStringSid()?
Thanks
Ramesh
Sorry for reviving a graveyard post, but I had the same issue a year or so ago, managed to find out why and I figured I'd at least share the reason behind this behavior.
When using the System.DirectoryServices.Protocols namespace, all attribute values should be either a) a byte array, or b) a UTF-8 string. Thing is, the developers at Microsoft figured that they should help people by returning a string when the byte array returned from the underlying LDAP API can be formatted as one, and the byte array itself when the UTF-8 conversion fails. However, this is only true for the indexer of the DirectoryAttribute class, and not for the iterator (which always returns the byte array) or the GetValues method.
The safest way to always get a byte array when you want the SID is, as previously mentioned by others, the GetValues method.
I came through the same. Found this behavior normal when deal with ForeignSecurityPrincipals, however recently found this when translate attributes of built-in groups from some old Win 2K3 domains.
I don't like this as can't just ask the result attribute to tell me via GetType() what type are you and what should I do with you ( GetValues(Attribute.GetType()) ). One of the solutions was reading all attributes definition from AD schema, but this part might be a bit heavy (depends what you're looking for) although it was only a small part of overall AD processing the solution was performing.
Cheers,
Greg
I'm trying to store email addresses in Salesforce.com from another service that allows invalid email addresses to be specified. If one of those bad invalid email addresses is sent to Salesforce.com via their Web Services API, Salesforce.com will prevent the record from saving with an INVALID_EMAIL_ADDRESS error code.
I can't find any documentation on how to disable validation on Email fields, so it looks like I'll need to validate them in my integration and pull out those that fail. Does anyone know the validation process Salesforce.com uses to determine if an email address is valid? All I have right now is a Regex, but I'd like it to match Salesforce.com's process.
EDIT: For reference, here is my Regex (I'm using C#/.NET):
^(\w|[!#$%'*+-/=?^_`\{\}~.&])+#\w+([-.]\w+)*\.\w+([-.]\w+)*([,;]\s*\w+([-+.]\w+)*#\w+([-.]\w+)*\.\w+([-.]\w+)*)*$
Summary: we're using the following .NET RegEx:
const string SFEmailRegExPattern = #"^[A-Z0-9._%-]+#[A-Z0-9.-]+\.[A-Z]{2,4}$";
If you can believe SF's own documentation then:
For the local part of the email address we accept the following characters. The local part is anything before the # sign.
abcdefg.hijklmnopqrstuvwxyz!#$%&'*/=?^_+-`{|}~0123456789
Note: The character dot . is supported; provided that it is not the first or last character in the local-part
For the domain part of the email address we accept. The domain part is anything after the # in an email address:
0-9 and A-Z and a-z and dash -
A couple of people have coded this up as a Java regex as:
String pat = '[a-zA-Z0-9\\.\\!\\#\\$\\%\\&\\*\\/\\=\\?\\^\\_\\+\\-\\`\\{\\|\\}\\~\'._%+-]+#[a-zA-Z0-9\\-.-]+\\.[a-zA-Z]+';
although to me this looks like it fails to reject an email that starts with a "." so isn't perfect.
I don't know how salesforce.com is validating email addresses, but since you are using .NET I'd suggest you to consider an email validation component like our EmailVerify.NET, which is 100% compliant with the current IETF standards (RFC 1123, RFC 2821, RFC 2822, RFC 3490, RFC 3696, RFC 4291, RFC 5321, RFC 5322 and RFC 5336) and does not suffer from ReDoS: if needed, it even checks the DNS records of the email domain under test, its SMTP availability, validates the related mailbox and can even tell if the target mail exchanger is a catch-all or if it is a disposable/free email address provider.
I don't know what salesforce.com uses (and I don't think there's any way for you to find out), but \b[A-Z0-9._%+-]+#[A-Z0-9.-]+\.[A-Z]{2,4}\b from here is a commmon one and should work for most of the cases.
I've looked previously and not been able to find a definitive answer on exactly which rules SFDC applies to the native "Email" field type. The quickest path to success that I would suggest would be this:
in your initial data integration from the external application, map the email field that you describe into a new (non-email, just text 255) custom field in SFDC.
if this is a one-time dataload, run a separate process that, for every row in SFDC with this custom field populated, attempts to copy the contents of this custom field to the native email field. If any row fails with the email validation error, you just skip it. Then you can decide what to do with the non-compliant addresses.
if this is an ongoing integration, it may be better to do something like attempt to insert new rows one-at-a-time via WS API, and if the email validation exception is thrown, you catch it and either insert the record without an email address, store the bad email in a different field (like a custom field called "non-compliant email address"), or skip the row altogether (if bad emails == bad record).
Hope that helps.
Apex has native Pattern and Matcher classes, based on java.
You can validate your email addresses in Apex code, using your RegEx expression as a string
String emailPattern = {your regex expression);
Boolean validEmail = pattern.match(emailPattern, emailAddress);
You can't definitely create common regex for salesforce email, due to inconsistency of their own requirements.
The one rule is about to give possibilities to put IP address after the local part. Example -> email#123.123.123.123.
The second is about do not allow digits in top-level domain.
For example: test#test.com1
So, they are mutually excluded.
But as I understood the email address with IP after the local part is more important and commonly used comparing with numbers in top-level domain.
Here is some examples of valid/invalid emails for salesforce.
Valid:
a#ua.fm
email#domain.com
firstname.lastname#domain.com
email#subdomain.domain.com
firstname+lastname#domain.com
email#123.123.123.123
1234567890#domain.com
email#domain-one.com
_______#domain.com
email#domain.name
email#buyacar.co.uk
ail#github.dennis.co.uk
email#news.i.ua
firstname-lastname#domain.com
Alexka1!+1123klsn&*^%$%$#^^^#a3432.4s.c4p.uk
frw...??//||/wt'f`fe#wfwfg-----wfwef.mm
a..#test.jp
abcdefg.hijklmnopqrstuvwxyz!#$%&'*/=?^_+-`{|}~0123456789#acme-inc.com
Invalid:
aasd#sdfжжж.rf
plainaddress
##%^%#$##$##.com
#domain.com
email.domain.com
email#domain#domain.com
.email#domain.com
あいうえお#domain.com
email#domain.com (Joe Smith)
email#domain
email#domain..com
email#domain.com.e
email#domain.com.33
As result of above, the final regex is:
/^(?!\.)(([^<>()\[\]\\a-zA-Z0-9.,;:\s#"]*(\.[^<>()\[\]\\.,;:\s#"]+)*)|(".+"))[a-zA-Z0-9.!#$%&'‘*+\/=?^_{|}~-]+#[\w.-?]+.[A-Za-z]*(?
Here is a regular expression based on this help page + a lot of experimenting in Salesforce:
^(?=(?:\([^)]*\))*[^()]+[^#]*#)(?!(?:\([^)]*\))*\.)(?:(?:[\w!#$%&'*+-/=?^`{|}~]|\([\w!#$%&'*+-/=?^`{|}~]*\))+|"(?:[\w!#$%&'*+-/=?^`{|}~]|\([\w!#$%&'*+-/=?^`{|}~]*\))*")#(?:\([A-Za-z0-9-]*\))*(?:(?:[A-Za-z0-9]+|[A-Za-z0-9]+(?:\([A-Za-z0-9-]*\))*-(?:\([A-Za-z0-9-]*\))*[A-Za-z0-9]+)(?:\([A-Za-z0-9-]*\))*)(?:\.(?:\([A-Za-z0-9-]*\))*(?:(?:[A-Za-z0-9]+|[A-Za-z0-9]+(?:\([A-Za-z0-9-]*\))*-(?:\([A-Za-z0-9-]*\))*[A-Za-z0-9]+)(?:\([A-Za-z0-9-]*\))*))+$
See this Demo. It gives the same validation result as Salesforce for all the values I could think of testing - copied below - any counter examples are welcome...
************* VALID *************
a#a.a
-#a.a
a#1.a
a#a-a.a
a#a.a-a
!#$%&'*+-/=?^_`{|}~#test.jp
a..a#test.jp
a..#test.jp
"a"#test.jp
""#test.jp
(comment)(comment)a(comment)(comment)(comment)#(comment)a.a
(comment)(comment)a.(comment)(comment)(comment)#(comment)a.a
(comment)(comment)a(comment).(comment)(comment)#(comment)a.a
a#(comment)a(comment)-(comment)a(comment).a
john.doe#(-comment)example.com
john.doe#example.com(comment-)
()a#test.jp
(a)a#test.jp
a(a)#test.jp
a#(a)test.jp
a#test.jp(a)
simple#example.com
very.common#example.com
disposable.style.email.with+symbol#example.com
other.email-with-hyphen#example.com
fully-qualified-domain#example.com
user.name+tag+sorting#example.com
x#example.com
example-indeed#strange-example.com
test/test#test.com
example#s.example
"john..doe"#example.org
mailhost!username#example.org
user%example.com#example.org
user-#example.org
1#1234567890123456789012345678901234567890123456789012345678901234.1.2.3.4.5.6.7
************* INVALID *************
a#a
a#a.
a#-a.a
a#a-.a
a#a.a-
a#a.-a
a;a#test.jp
.a#test.jp
";"#test.jp
"#"#test.jp
"a#test.jp
a"#test.jp
a""#test.jp
""a#test.jp
()#test.jp
)(a#test.jp
(a)#test.jp
(a#test.jp
(())a#test.jp
(comment)(comment).(comment)a(comment)(comment)#(comment)a.a
john.doe#(comment).com
a#(comment)a(comment)-(comment)(comment).a
Αθήνα#email.com
admin#mailserver1
" "#example.org
"very.(),:;<>[]\".VERY.\"very#\\ \"very\".unusual"#strange.example.com
postmaster#[123.123.123.123]
postmaster#[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334]