Client Side Validations Gem - is uniqueness validation is still working? - ruby-on-rails-3

I am using client side validations gem and in the official documentation is recommended to turn off uniqueness validation due to security reasons:
By default a uniqueness middleware is added. This can be a potential
security issue.
So, following the recommendation I uncomment the following line
ClientSideValidations::Config.disabled_validators = [:uniqueness]
in the config/initializers/client_side_validations.rb file.
Anyway, when I am typing some text in fields that needs to be unique the following request is send by client side validations scripts which I believe is checking if the type in text is unique:
When I type some name that is already taken, the request status is still not found, so I believe the validation is turn off, but why this request keeps going on and is there anyway to stop them?
I know the client user probably will not know what is going on at all, but I just found it unappropriate to send a request on each field text change.

If I understand you well you disabled uniqueness remote validation but the app keeps sending the request, right?
If that's the problem, try restarting rails server.

Related

What information is logged by IdentityModel when ShowPii is set to true?

IdentityModelEventSource has a property called ShowPII that means that Personally Identifiable Information will be added to the logs (in relation to security). This value is used to decide when to log some OAuth2 sensitive data.
I am trying to understand what kind of Personally Identifiable Information will be logged:
Client ID? (aka Client Key, Consumer Key)
Client Secret? (aka Consumer Secret)
Json Web Tokens? (aka JWT)
Access Tokens?
Refresh Tokens?
Kerberos Tickets?
PKCE Values?
Authorization Codes?
I know it cannot get access to usernames and passwords because they are only exchanged directly with the IDP.
But but I need to know if I need to find a way to lock down my log files because it will have data that constitutes a security vulnerability.
This is possible log messages of IdentityModel: LogMessages.cs
About
I am trying to understand what kind of Personally Identifiable Information will be logged
I won't copy-paste log messages from there (especially, as they can change at any moment). You can check them yourself and decide what should be considered as the PII.
But here's an interesting example:
"IDX10615: Encryption failed. No support for: Algorithm: '{0}', SecurityKey: '{1}'."
and this is how it's used:
throw LogHelper.LogExceptionMessage(new SecurityTokenEncryptionFailedException(LogHelper.FormatInvariant(TokenLogMessages.IDX10615, encryptingCredentials.Enc, encryptingCredentials.Key)));
If you'll follow the track you'll find out that encryptingCredentials.Key will be logged if ShowPII = true and won't be logged if ShowPII = false.
Of course, depending on your use case, this particular message may never appear in your logs. And not all messages so outrageously leaky. But you never know:
your use case may change
you may be mistaken about the set of messages IdentityModel can emit for your use case
IdentityModel code may change, and you may forget to check if messages' set is still secure
So about
if I need to find a way to lock down my log files
Yes, you definitely need to.
Or better yet - don't use ShowPII = true in production for monitoring, use it only in development environment for debugging purposes.
Looking at the source, it appears that when ShowPII is on - it will do two things:
Replace all parameters passed to library-specific exceptions with their data type names
For all system exceptions - replace inner message with exception type name
In this context "library-specific" is an exception that is of type Exception and its full type name starts with "Microsoft.IdentityModel." (library defines a few)
Depending on your use case you'd see a variety of parameters that can be logged with custom exceptions. A quick search for FormatInvariant yields quite a few for your consideration.
Again, depending on how you use it, you might get a better idea of what the error messages are by looking through relevant LogMessages.cs file on your specific namespace.
P.S.: on a side note, it appears that default ShowPII setting is GDPR-compliant

Display server-side validation error in form semantic-ui

The client side form validation rules in Semantic UI are nice, but we all know the client cannot be trusted, so naturally we need to validate on the server.
Anyone knows how to have server-side errors displayed like the "native" SUI validation errors. Users shouldn't see any difference regarding where validation is done.
So far I've combining the SUI form validation with the SUI "api" function. This is because the API function gives med onFailure callback from the server, where I can then parsing the server errors and add with "add errors" form command.
But it never worked perfectly.
With such a basic requirement, how would you create a form with both client- and server-side validation in SUI?
Kind of like in this post but without the Meteor, just plain HTML.
This SS question is also similar, but the responses are not quite there.
Update
First, client validation is run, and only if this succeeds, we call the server. This means we're in the onSuccess.
If there are server errors (validation MUST always be done on server, client can't be trusted), I think they can be parsed and added like this:
$form.form('add errors', formErrors).
(based on a discussion on semantic-ui forum on Gitter, March 9th 2016)
https://gitter.im/Semantic-Org/Semantic-UI

Debugging ActiveMerchant; need full request and response. How to?

Rails 3.0.10 and activemerchant gem 1.29.3
My app works fine in sandbox, but transactions in production mode are failing with "Security header is not valid", "ErrorCode"=>"10002"
We initiated a support request with paypal, after reviewing all the configuration parameters a million times and they feel we're hitting an incorrect endpoint. They've asked for a full trace for the transaction, including headers, etc, so I'm trying to figure out how to do that. I found this article
which suggested adding this to the config block
ActiveMerchant::Billing::PaypalGateway.wiredump_device = File.new(File.join([Rails.root, "log", "paypal.log"]), "a")
But that just results in an empty log; nothing gets dumped to it.
So, how can I obtain this info from the GATEWAY object, if possible? Here's the production config, the format of which is identical to what's used in staging env.
::GATEWAY = ActiveMerchant::Billing::PaypalGateway(
:login => 'me_api1.blah...',
:password => 'string...',
:signature => 'longer string...'
)
Thanks.
Needed to add the additional line as follows:
ActiveMerchant::Billing::PaypalGateway.wiredump_device.sync = true
Within the same config block in the environment
Somewhere in the class library you're using there should be a function to output this for you (if it's a well built library, that is.)
Even without that, though, you should be able to look in that PaypalGateway function to see where/how it's setting the endpoint. It's either hard-coding the value or it'll be setting different endpoints based on some sandbox option you have configured somewhere else in the class.
It's hard to tell you more than that without getting a look a the actual class library you're using, but I can concur that it must be either incorrect credentials or an incorrect endpoint. I've never once seen that security header error when it wasn't simply invalid credentials, which means either your values are incorrect or you're hitting the wrong endpoint.
If you want to post that whole function (or maybe even the whole library as the endpoint could be getting set from some other function) I can take a look and find the problem for you.

Java Server Side Error message validation without actually submitting an application

I am trying to create a testing application to validate server side error messages. Right now our framework is such that each time a incorrect value is entered in a field and the submit button is clicked and on submission, the error message displayed on the page is captured.
Is there anyway I can bypass this technique, such that the validation happens only in the server side and is passed back to the client side, without having to reload the page each time.
Any other ideas would be much appreciated. Please try to ignore the lameness of the question :( I'm just starting off and wanted to try something new to reduce the time taken to capture the error messages.
Thanks a lot..!!
Use AJAX, Luke!
There are a lot of options to do this. You may use jQuery.ajax for sending your form data to some validation servlet. Or you may use JSF for it. It largely depends on your framework and/or architecture of your application.

is possible to keep session alive using NSURLConnection doing different requests?

I am using NSRULConnection to make http request on my iphone application. All works just fine.
The problem is after logged in I need to keep the same session to get data from the server.
I read a few posts saying all I need was using the same instance of NSURLConnection and it would use the same session... if that is true, that doesn't make sense to me, cause the NSURLConnection is not mutable and there is no method to change the request since I have to access different pages.
Is there anyway simple way to keep a session using NSURLConnection.
If you are managing sessions using cookies, there is no need to do anything special to achieve session management.The URL loading system automatically sends any stored cookies appropriate for an NSURLRequest. unless the request specifies not to send cookies. So, your sessions should be managed automatically for you.
However, as the Apple's doc says, if someone has set the cookie-acceptance policy to reject all cookies or only accept cookies selectively, you might be in a fix (you can change the cookie acceptance policy yourself too). In such a case, you might resort to URL based session-management; in which you append a session-identifier to the URL as a parameter (You can get this identifier as a part of the successful log-in response), which can be extracted on the server-side. This, however, is considered really bad practice.
Another way, which I have come across more often, is to get a session-identifier as part of the response for a successful log-in and include that identifier in all your subsequent requests as a parameter. Although this would require a major change in the way the server handles the sessions.