based on the documentation the validation response looks like this
{
"success": true|false,
"challenge_ts": timestamp, // timestamp of the challenge load (ISO format yyyy-MM-dd'T'HH:mm:ssZZ)
"hostname": string, // the hostname of the site where the reCAPTCHA was solved
"error-codes": [...] // optional
}
I wonder whats the purpose of the timestamp field in the response. Do I need to validate it?
I assume each validation token can only be used once and they expire after some time. So I shouldn't have to worry about the token reuse problem. I can't think of any exploit one could do even if the token doesn't expire at all.
The same goes with hostname. Since the site-key and site-secret must match so I shouldn't have to validate that field either.
Do they exist only for the purpose of logging?
Related
Here is my script:-
if (!isset($request->security_token))
{
// Provide security token
$error = TRUE;
$err_message[] = Lang::get('caption_validation_error.ser_valid_security_token.value');
$err_validation[] = Lang::get('caption_validation_error.ser_valid_security_token.value').' [security_token]';
}
It means, if a param is not "sent", then the validation will be triggered. However, if a param with "blank" value is sent, it must not trigger the validation.
However, when I am hitting the api through POSTMAN app, the security_token with blank value enters the !isset validation.
What am I doing wrong?
This is not that obvious why it's like this because it seems quite strange at first glance. However if you know a bit more about Laravel and you look at app/Http/Kernel.php file you will see in there:
\Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull::class,
which as you can find out from name converts empty strings to null. So in your case when you are sending empty parameter it's considered as null so !isset($null) will be true.
So you have 2 options:
remove this middleware from array - however it will affect the whole application so it might not be the best way if you are not sure about it
Assuming you want to trigger this validation only if parameter is not sent at all instead of
if (!isset($request->security_token))
you can use for example
if (!$request->has('security_token'))
Obviously it's not exactly the same - if you now sent this token and set it to null it won't be still executed but I believe when you now know what's happening with this empty string you can now adjust it exactly to your needs.
I am using Joi 10.6.0 in a Typescript project to validate the payloads on a series of requests. I am having the weirdest issue while validating a dynamic key in the payload:
validate: {
payload: Joi.object()
.pattern(/^id_[\s\S]*$/i, Joi.string().required())
.keys({
state: Joi.string().optional(),
presentation: Joi.string().optional(),
// etc
The idea is that I want the payload to include at least one key starting with id_. Alas, the required property on that pattern key seems to be totally ignored.
The regex matches the key correctly, and if I put other types of validation on the value, like Joi.number() the value is validated accordingly, but if I use string().required() and the value for id_ is not in the payload, the validation, bafflingly, still passes. In short, any validation seems to be applied, bar required.
I am sure I am doing something stupid but I am stumped -- I use Joi every day and I've never had such issues.
I know those token spring generates a UUID formatted string. One of my concerns is that it's not really "unique"; it is possible for the UUID to create a token exactly the same as a previous one (of course the odds are VERY small but still possible).
I'm using a database to store my user's token and I'm not sure if Spring checks if the token already exists before creating one in the database?
My second question is : Is it possible to create my own token instead of the UUID format, I'd like to have a more "unique" token like the current timestamp with the user's ID and username and then hash everything and that will be my token instead of 49784c38-43b1-.....
I already have a custom TokenEnhancer that I use to add custom info when returning the token to the client but how can I create a custom token before saving it in my database?
Thanks for you help!
Your TokenEnhancer can use any format it likes for the token value. The custom value will be the one that goes in the ToeknStore (that is the prupose of a TokenEnhancer).
P.S. If you think there might be a clash between UUIDs I think you probably need to do some maths and think again.
I apologize in advance if this question sounds naive to you.
The problem is this: I have this function and I want the callback function to send the "response" back to my server via Ajax.
function FbInviteFriends()
{
FB.ui({
method: 'apprequests',
message: 'Hi! Join me on XXXXXXX'
},
//My callback function
function(response){
//Send response to my server
}
Is there a way to check that the response I'm going to receive server-side is actually the same I got when the callback function is called and that the response hasn't been modified on the client-side by the user?
Thanks!
There's a few ways, but all of them fall on the same principle - you can never know for sure, so treat it with a grain of salt and validate.
That said, one way to put at least one usage constraint may look like this:
Page accessed: Generate a token GUID. Render it at the client.
Store in the user session the moment it was created/used, together with user profile.
Client appends the token to all Ajax posts.
Token is validated at the server; must match SessionID, user profile (if any), and maximum usage timeout.
If it fails validation, abort the operation.
In other questions, and in many places on the web, people note that browsers, IE especially, may cache Ajax requests in spite of headers to the contrary. The recommended fix is to add a timestamp or other "unique" field to each request, ensuring its uniqueness, and blocking caching.
My question is, should that always be in the query string? For GET requests, obviously yes, there's nowhere else it could go. But how about for POST requests, where there's both the query string (URL parameters) and a form body? Can you add a timestamp as a form field, or does it have to be in the URL/query string to have the desired effect?
How about raw JSON requests, where the post body itself is JSON, rather than form/url encoded name/value pairs? In that last case, the post body is binary. It seems unlikely that a timestamp within the post body would be noticed by any caching mechanism, and there's no form to attach it to, so that leaves the query string. Is cache-busting necessary in this case, or effective if done in the query string?