I have recently encountered one interesting behaviour.
If I authenticate through Chrome I don't get any extra user attributes I specified in config.
Assertion is not null
No attributes found
However, if I do the same thing with Firefox I receive attributes as expected.
Assertion is not null
Attribute number is greater than 0
CAS Attr Key: id
CAS Attr Value: 3500
CAS Attr Key: email
CAS Attr Value: username#mail.io
Does anyone have any ideas about what is causing it? Is it a bug?
Attribute release does not directly involve the browser. It is strictly client application server to CAS application server communication. The fact that the missing attributes coincide with a specific browser version indicates that there might be a flaw in the logic somewhere else in the client application.
You didn't indicate what CAS Client you are using, so no additional advice can be given.
Related
The User-Agent Reduction origin trial is valid from Chrome version 95 to 101 according to the official documentation, but looking at the token acquisition screen, it seems to be valid up to version 111. I am currently on version 109. Is this one excluded?
https://developer.chrome.com/en/blog/user-agent-reduction-origin-trial/
https://developer.chrome.com/origintrials/#/view_trial/-7123568710593282047
Also, this one is intended to test in a situation where the user agent string and javascript api have been completely removed or changed. Is there another way to test before they are completely removed?
We would appreciate it if you could enlighten us.
I have added the necessary settings to the response headers, referring to the official documentation, but it does not work correctly.
https://developer.chrome.com/en/blog/user-agent-reduction-origin-trial/
I am new to EMV development. My question is regarding Tag 91 (Issuer Authetication Data) which is sent by Issuer in EMV response. In my case, when tag 91 is missing in response packet then chip card decides to decline the transaction even if issuer has approved transaction online. So I am wondering whether Tag 91 is a mandatory tag which needs to be sent by issuer each time it approves a transaction online and what is industry wide understanding about it. Please let me know thoughts on it.
Also, In my case, Application Interchange Profile Byte 1, Bit 3 = 1 which means external authentication is required.
Are you working for Card Application or Terminal Application ?
Issuer authentication always have to be performed unless you are doing a partial chip implementation. I am sure you know that it is an additional level of security that ensures that the response came from the correct issuer.
When AIP B1B3 is on, it means card will expect tag 91.
In some cases it is even default. eg. D-PAS( Diners/Discover) AIP B1B3 is off, since it does not support External Authenticate. It is verified during second Gen AC. In such cases if the issuer wants card to not decline the transaction when ARPC not present, in the ACO( Application configuration Option), it is explicitly mentioned about partial chip implementation.
Check each payment scheme card and terminal specifications manual careful before you implement, as any loop holes in implementation may help a fraudster skip the security you wish to provide.Thumb rule, if you get ARPC from issuer, always sent it to card. Let the card decide.
From Card Application side I can add that "Application Interchange Profile Byte 1, Bit 3 = 1 means external authentication is supported, but not required. What does it mean ? Card may support Issuer Authentication, but may not required it for online transaction (issuer authentication can be mandatory or optional in card internal parameters). I.e. for optional it would be great to do auth, but if not - no problem, do online. And if Issuer have not sent tag 91 card may aprove transaction.
i've created a form with symfony 2, but my browser internet explorer 9 (running under vista) doesn't support HTML5. so i get this error message:
an exception occurs: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null.
i've tried this solution:
{# src/Acme/DemoBundle/Resources/views/Default/new.html.twig #}
{{ form(form, {'attr': {'novalidate': 'novalidate'}}) }}
but it doesn't change anything!
the submit of the form perfectly works on firefox. does anyone have a real detailled solution for IE9?
Thanks
Browser based validation is useful for giving the user instant feedback but you always need to re validate everything on the server side. As you discovered, not all browsers support validation. Plus, users can easily bypass browser validation and send bogus information back to the server.
Scroll down to the validation section here: http://symfony.com/doc/current/book/forms.html
People who want to comment on my answers should use the comment capability. Or make their own answer.
The novalidate attribute forces ALL browsers to bypass the HTML5 validation. But as already said, client side validation is not enough. When you actually read the error message your browser tells you, note the word SQLSTATE in it. SQL runs on the server side in a normal symfony application, so the error happens on the server, not on the client.
You should add assert annotations to you entity members to validate them on the server. This could look like this in the simplest form for an attribute $name:
/**
* #var string
* #Assert\NotBlank()
*/
private $name;
Then don't forget the import for the asserts:
use Symfony\Component\Validator\Constraints as Assert;
Of course, you may also use other ways to define your validation rules, like xml or yml config. Please refer to the specific section in the docs for more information.
I've got a self-signed certificate for multiple domains (let's say my.foo.bar.com & yours.foo.bar.com) that I've imported using Keychain Access but Chrome will still not accept it, prompting me for verification at the beginning of each browsing session per domain.
The Certificate was generated using the x509v3 subject alternative name extension to validate multiple domains. If I navigate to the site before I import the certificate, I get a different warning message than after importing. Attached below is an image of the two errors (with the top being the error before imported)
Is there any way to accept a self-signed multi-domain certificate? I only get warnings in Chrome, btw. FF and Safari work great (except those browsers suck ;) )
UPDATE: I tried generating the cert both with the openssl cli and the xca GUI
The problem is that you're trying to use too broad a wildcard (* or *.com).
The specifications (RFC 6125 and RFC 2818 Section 3.1) talk about "left-most" labels, which implies there should be more than one label:
1. The client SHOULD NOT attempt to match a presented identifier in
which the wildcard character comprises a label other than the
left-most label (e.g., do not match bar.*.example.net).
2. If the wildcard character is the only character of the left-most
label in the presented identifier, the client SHOULD NOT compare
against anything but the left-most label of the reference
identifier (e.g., *.example.com would match foo.example.com but
not bar.foo.example.com or example.com).
I'm not sure whether there's a specification to say how many minimum labels there should be, but the Chromium code indicates that there must be at least 2 dots:
We required at least 3 components (i.e. 2 dots) as a basic protection
against too-broad wild-carding.
This is indeed to prevent too broad cases like *.com. This may seem inconvenient, but CAs make mistakes once in a while, and having a measure to prevent a potential rogue cert issued to *.com to work isn't necessarily a bad thing.
If I remember correctly, some implementations go further than this and have a list domains that would be too broad for second-level domains too (e.g. .co.uk).
Regarding your second example: "CN:bar.com, SANs: DNS:my.foo.bar.com, DNS:yours.foo.bar.com". This certificate should be valid for my.foo.bar.com and yours.foo.bar.com but not bar.com. The CN is only a fallback solution when no SANs are present. If there are any SANs, the CN should be ignored (although some implementations will be more tolerant).
What is the "official" url I should use if I want to indicate just a resource that fails as soon as possible?
I don't want to use www.example.com since its an actual site that accepts and responds requests and I don't want something that takes forever and fails from a timeout (like typing using a random, private IP address can lead to).
I thought about writing an invalid address or just some random text but I figured it wouldn't look as nice and clear as "www.example.com" is.
If you want an invalid IP, trying using 0.0.0.0.
The first octet of an IP cannot be 0, so 0.0.0.0 to 0.255.255.255 will be invalid.
For more info, see this question: what is a good invalid IP address to use for unit tests?
https://www.rfc-editor.org/rfc/rfc5735:
192.0.2.0/24 - This block is assigned as "TEST-NET-1" for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. As described in [RFC5737], addresses within this block do not legitimately appear on the public Internet and can be used without any coordination with IANA or an Internet registry. See[RFC1166].
Use .invalid, as per RFC 6761:
The domain "invalid." and any names falling within ".invalid." are special [...] Users MAY assume that queries for "invalid" names will always return NXDOMAIN responses.
So a request for https://foo.invalid/bar will always fail, assuming well-behaved DNS.
Related question: What is a guaranteed-unresolvable (but valid) URL?
if it's in a browser then about: is fairly useless - but it would be better if your service returned the correct HTTP status code - e.g. 200 = good, 404 = not found, etc.
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes