This is YouTube's 500 page. Can anyone help decode this information?
<p>500 Internal Server Error<p>
Sorry, something went wrong.
<p>A team of highly trained monkeys has been dispatched to deal with this situation.<p>
If you see them, show them this information:
AB38WENgKfeJmWntJ8Y0Ckbfab0Fl4qsDIZv_fMhQIwCCsncG2kQVxdnam35
TrYeV6KqrEUJ4wyRq_JW8uFD_Tqp-jEO82tkDfwmnZwZUeIf1xBdHS_bYDi7
6Qh09C567MH_nUR0v93TVBYYKv9tHiJpRfbxMwXTUidN9m9q3sRoDI559_Uw
FVzGhjH5-Rd1GPLDrEkjcIaN_C3xZW80hy0VbJM3UI5EKohX35gZNK2aNi_8
Toi9z3L8lzpFTvz5GyHygFFBFEJpoRRJSu3CbH5S2OxXEVo4HgaaBTV7Dx_1
Zs1HZvPqhPIvXg9ifd4KZJiUJDFS8grPLE7bypFsRamyZw-OCVyUHsGQKBwu
77pTtRwpF3hOxYLxM4KnAyiY1N6yrASSWyaeumRDENAoEEe8i8MRxzifqHuR
leatvNMiwsg1pbSl7IIiaKljZaD9UkRms4Kvz1uYUNk4AwXnJ9-Wq44ufMPl
syiHp_LwaeqyuxXykJMl-SA9p05VrJc4kCETUW3Ybp0yTYvVrqggo56A0ofC
OiyAmifQA9pdYVGeumrQtbFlFyDyG9VKNpzn5lqutxFZPsS8xjiILfF3bETD
H4aUb5fT4iERFsEL7S-ClsXiA4yAJdAcNH-OhGg9ipAaIxRRTOR5P1MYx6s6
-OrqgpT5VEaEx2hMpS1afaMd2_F21sxvcz2d8sCpEceHHSfsntTth6talYeD
4l63aUTbbCKV1lHxKWxdUjACFKRobeAvIpcJPcdHSN3CNQI-LlIWIx9jeyBU
tDcL6S6GpRG_Z2of9fmw0LHpVU5hKlQ3lCPd4pVP6J02yrsBi0S9OLoE9jmM
T2FfCvU1sWUCsrZu4-UPflXMyRnFK8aN8DYiwWWE8OvnLQ-LIaRDhjp29u9a
LT6Lh4KxEmWF5XeZTwrzJxtuDLVomxVD5mpwFvK0YSoaz9dnPGXb0Fm2txSL
BvGssSrWBJ4FeR6eEEkd_UkQ-aUnPv2W-POox17n54wzTwLugYjslRenMzmk
I4_jlXcx9NpKmUg7Pa0qJuaElt-ZymPv6h0cXRUlyZtS0iT9-CQOHWLYMi3I
kKrYa6bKUCAj058JEderSnbXqGEMvwBeZ_xgJpAjJiSgMOxJPokhbS6ezIv4
1JNr_dvQyvu4vh-YQNZ37fNTqQcoDZtYflBsJjuGrJlmIcqBYufB9g6nUaOE
xPAKjPdvZ_z1Rn_8sWVf8NHNBBKGe5lgDgBxypsV0kIwVa9QOlehivOaieBI
tmqHNdQIfdob0XUTEBPSeLj9hmw3Bqplc3gqUfFhIvpHml6dOTbjBhfkq0TE
5yCRHL2VSe2Xt9_i8SPQA2yCtJVO8HP6pnohmxqlBWSTE8Xj87PI6quX7f9i
0W6PdtkMYaGJsd_Ly_4Ag-KmGNHN585tF9eC5HeQ8Gz-vHZWOUiM4OQAG9UA
31ENOAjHtYb--ketbUcdX_FdjGiPtI_GxYeBqEShICotcd-S-E3bEGO-77M2
CuUUdB1AUYVDZR81XejVG5kSWsrz-p1qZ-6sSpSHCp114C6PheQPCwRHEr_1
AS-DkZfIuZ-w8XAo6pHIwvnv0dORSo-hPFgw1rw2VE4aKsgeMc7ZoPUxby1d
Zr-o-0X4ZMgxoQHw_Ub27rTTHxS5Czt_vgBPq7k5OK5dm6b7JCs6Dbn2dsIA
AakPL26t4smr8IiPAnqNC2sn7vxSiAe9mTJ670eNc6C9dCSGwqzqSURiLHmT
kFyLhNSOdipttECmSSA1qh_E0K4LUhiOq7MFDEzg9CLD8kuJrqpEGgltYpD-
8lk7KEpyjMqbWFs-qeD8uJpsVfY2ac1C67OmyGzkERVoC245-YXuNCP8KUZH
LGzRm9jXwUP_piDETX0N5xj34VOCfUTffT1WlWHmB9WRPhwjIsYYy_kgR-uT
kIEDQ23NVUEGgDoryl-ymysIfwifjq-lPB3e85dz1PajNxawsCrKNeR_4hhq
zE_E4ete1EgXeAYoeH4UIgrPGXDD-KfoNoB6viNs0GzNU9czD9Avr-tDtARO
HBLSLIVRYq8caMA-jvpplTOMoDdmUMUWytf4Y_F5tKTpNtLPaAe1py1IgZBl
lfAGY9L_k5slelh_9gUBEkURxS2oMGf2gdSeDdRBxKKx5tF1b-cuMLK6JYZJ
vbGFYSsSENOkHrHEo9NdTwTi7NON9ZgRJgh7OaENK4TFCXrhKc4C6cyJs-V_
HZ0Q-B8XDyjL0qudg_0rJbjTNpNZajT_1WGsnhsTTAgMCGtTsj1T8vNx2LuX
lPQV30nUKpukdCP3zuiE9_aeJQ-nzf3dMQ-KnZU5APmGcIP_u2be6blieMWH
qVax1asKmuIjslh49ceM6lRt3Ia2bHUB8b1TMSjU4I79KPqc3clDnD8quNnU
cRkgfJ_8LCEoH7jml_2TNV0fLuH_9IOXF3jKjhT9K5f-e5N06GmPQLzdqzeQ
MnEtHuDcf4IizyKnB5GUXoNfQxbScQEzztQ_nHMYfF-E8KqoxxlK-Z0wfEDv
dJpL3mcNfFu_vz-_LJ0oI4dE0-vthsxbpTxVQkdI0E5XSi4nYfLqhXompk4j
gpxcHBjsXVbWcnelWhhQP15gCApj6Gz_ddRtk_uxiyiqZ44oUUDcl1KeWMTf
yhKDj7jgGNzTOkUsXZRPb9M77-ZYPuL2wR68E3b9PC_mS6HBHiUxQ7pXvkwS
Bi2CoFgd9SqBXk2O5I_BPaEoA8Aorazw4OvDrmTQrCk4OkGPKRukE4Ci2RMq
TZIYbBz-v3QxmOKHJoMXPNOfj93TRWpmlAd6iHCH6BVlSdfgfjdbHeD0b0ct
qXC_-S5fr1XFBuaZwaUTrBPxU-3IxWLp-dx7wpKcFykqKnByYpkzR3twKEXc
z--CZV79Qk3ZTMY9ATia4HbyhoAqY_hV9GKAHQdU_C-9qwYt0rliNUcizlBc
RHcwzoMyx30ciwbE8e9QsEH_AMa3E2ezuhjTqQlAG33_Gy5Bwe7fj6zNR0ud
jjpcNVf-wprWHEYxMcKwjCQvEHBtv6TnCHkgi_AOtPzzm3aYkMc_ysdNAnI7
DE_T9S5Mkcs6VdT2DWgUN_UC-oAw27xej0aTIn0GckXPDcLBgvrUhUPU3FRn
lW65syvFvxFmBOiCAEHD1q6Is1XhIf8vE6y0FMdNEWSMUW5rQG8f3KP_pjqG
XlUHnGrQPQysylrczHOj4E3WTT918xg2vrXVraDJbCYnJpaWp8m94iqZw2gJ
I_0UWOAZJMCYWz5jYf2DanCOBaGeZIO-UsWorP6YV3yHehirZ_Lc6KtaUorb
bm_BnnCqGVZypL4k6cDy-4GyO2GNohXzN-VWqbAIUQIat9w6RsDpzpS2DIap
96aMBDg24D73RhFTEgCSunPpbbGrDVU3GFkuTGFFBQWNfAU_F22XtoPr_ZB0
1zZPrBVXrEhebvrzp0Z31_sIT8zLop_oaSRvykbyJKKxucARfPee-d0xlgWN
WwKKtl49WVMhhu0OfDScH3knAVdv0LDAyt1fo3WF8jxdp7J9Hn3OWF3rcn0p
zw0gt6YV_6FRy_UbZmpLBvEhZQKUfKuxp6LK-SfHOilT29ERg9LJZhnyluTV
HELRtkJIcHzvphXupCIaIgZispYxHNSmAfze2cshWBYizGTBSKXWgrJeo7Q6
kEjim72yKaJ8JaLzMQFPxtQxhtvHRw94dCuXcajg3nE_r_9t7D8RicqF-CVV
tvp-rHMPhhizlgfixHWXrPB7reTtftT64pOSl5vUop8gTlbeW5Kg7WQAPNfp
zUH8YcAo0xDLJHA-FgTM4mYGih41rKaKKteWRFGU-fIyEzeO1s35tbGzlZ7R
btUG_fCpIbaJmucMZK9OzVBSfBgTBtFSesqKq6hIc8HctGcj5LPUfP9DRqqe
CrBi6bPjTlzrjaxJoU6oRq4ZtiBG38skOAaCUk61tpjilkq1fmWe2ByvLXhp
O2furZoiwNrizYmUmAW3ak3iSneScA64M-9apdZwhhEgpqyw5mUMYNT5SOOf
xZePlgXxhlL81t3KlofdbzT0w6tlbbT0NSbj9Q_zNkeZ8ar5aeMgTR-pJACg
baB20YVezziX-yboCF-uIptCTFNV
(Source: this post on HN)
The debug information contained in the (urlsafe-)base64 blob is likely encrypted.
Think about it from Google's perspective: You would want to display a stack trace, relevant headers of the http request and possibly some internal state of the user session to help a developer debug the situation. On the other hand all that information might contain sensitive information that you don't want the general public to see or that might endanger the user if he copy'n pastes it in a public support forum.
If I was to take a guess of the format I would imagine:
A public identifier of the key used for encryption (their servers could use different keys then)
The debug data encrypted using an authenticated encryption scheme
Additional data for error correction when OCR has to be used
For statistical analysis of the format it would be interesting to sample a lot of these error messages and see if some parts of the message are less random than you would expect from encrypted data (symmetrical encrypted data should follow a uniform distribution).
It looks like you are not the only one who is looking for some secret messages in YouTube error page. It seems that you can decode it using Base64.
Here is how:
http://www.cambus.net/decoding-youtube-http-error-500-message/
In a nutshell:
Sadly, contrary to my expectations, there doesn't seem to be any
hidden message… Screw you, highly trained monkeys!
I guess it is just another Easter Egg similar to 'Goats Teleported' performance counter Google Chrome had:
https://plus.google.com/+RobertPitt/posts/PrqAX3kVapn
But I guess unless you look like this, you can't be 100% sure.
It's entirely possible that this is random padding to avoid the "friendly" IE error pages that show if your error page does not contain more than 512 bytes of HTML. It would be base64 encoded if it were simply random bytes.
Imho this is all about customer care.
Actually there would be no need to send the error/debug message to the customer, because, I guess, it's already handled internally.
So:
why do we see this?
and why do they crypt it?
and is there really no hidden message for us?
Although the error might be handled and resolved internally, this does not necessarily satisfy a customer, who is not able to use the product. They pretty much do crypt by a good reason as this debug message might reveal more than a typical admin is used to.
And also there is no need to hide a message for us. Why? Because we NEVER stop until we find something.
I think:
internally the error is dealt with
external users might have something in hand to tell a technician if necessary and in return can get an approximation of ongoing problem
All in all nothing special about it and i think linking e.g. to the inf. monkey theorem is a bit overspectulated...
Error 500 means google has a problem which can not resolve. So when reporting a bug the most important thing is to prepare reproduction steps. So I tried to find an answer of the question "When this happens?"
I found this post in reddit: https://www.reddit.com/r/youtube/comments/40k858/is_youtube_giving_you_500_internal_server_errors/?utm_source=amp&utm_medium=comment_list
As resume:
It happens on desktops (www...), it works ok on mobile version (m...)
It happens for authenticated users. For anonymous users is working fine.
The problem is resolved after cookies are cleaned.
So I would give a direction: try to find the key in the session cookie. I hope my 2 cents will help.
Related
Over the last several weeks, my Rails 6.1 app has been raising hundreds of exceptions like the following:
An ActionDispatch::Http::Parameters::ParseError occurred in regdevs#create:
859: unexpected token at
'utf8=%E2%9C%93&authenticity_token=fnrg63qtelQvkQx9NQx8SaZIp7mR500toEiWdaJe91
%2FOzsEvRbGD4Ow6NNADCtjw7H3EkDvFZVGP4gQkGZceEw%3D%3D&user%5Bemail%5D=jrmills91
%40hotmail.com&user%5Bfirst_name%5D=wJAhzNnPWbqMdfH&user%5Blast_name%5D=tKdp
IVXJlneZbiuA&user%5Bnickname%5D=lBdbyYgiaHt&user%5Bpassword%5D=0SgLpVuf5Wqs
%21&user%5Bpassword_confirmation%5D=0SgLpVuf5Wqs%21&user%5Bterms_of_service
%5D=1&commit=Complete+registration&g-recaptcha-response=dzghTWcBpmI'
The error occurs when "someone" tries to register for a new account (via Devise) with bogus credentials. It clearly looks like some sort of attack.
I have two questions:
How can I find out more about this specific 859 unexpected token error?
Should I be concerned? The recaptcha guard seems effective in blocking account creation, but I wonder if I am missing something
I partially decoded the response by hand mostly just to see what it looked like.
utf8=%E2%9C%93
authenticity_token=fnrg63qtelQvkQx9NQx8SaZIp7mR500toEiWdaJe91/OzsEvRbGD4Ow6NNADCtjw7H3EkDvFZVGP4gQkGZceEw==
user[email]=jrmills91#hotmail.com
user[first_name]=wJAhzNnPWbqMdfH
user[last_name]=tKdpIVXJlneZbiuA
user[nickname]=lBdbyYgiaHt
user[password]=0SgLpVuf5Wqs!
user[password_confirmation]=0SgLpVuf5Wqs!
user[terms_of_service]=1
commit=Complete+registration
g-recaptcha-response=dzghTWcBpmI
The first line is utf8= and then that is the unicode for checkmark. Perhaps that is part of the captcha?
The user names etc clearly look bogus. I bet jrmills is getting lots of weird email. :-)
The ParseError is defined in parameters.rb and you can see the call that created it inside parse_formatted_parameters. The only place that calls it is from request.rb.
From the comments in the code (and what I would expect), if the authenticity_token doesn't match, an ActionController::InvalidAuthenticityToken should be raised. So, the parse error (I'm guessing) is lower down but I can't spot why the JSON or Ruby code would be complaining. I think I would have written that piece of code differently: captured the error and included the original error message with the new error -- but... such is life.
I would attempt to track down the IP address where these are being sent from and block that IP address if possible or at least see if it is the same address or if they form a pattern.
Depending upon what you are protecting would alter my level of concern. It seems plausible that a validation on the first and last name could be written that would reject this particular style of name. i.e. capital letters in the middle of the name? You could also flag any email going to "bogus" places like hotmail, yahoo, gmail, etc and require them to go through a moderator before being approved.
It also seems plausible to rig up a test case using this response to recreate the issue. Then add debug code to the Rails code until the precise reason for the exception is better understood.
I'm trying to log to file / seq an event that's an API response from a web service. I know it's not best practice, but under some circumstances, I need to do so.
The JSON saved on disk is around 400Kb.to be honest, I could exclude 2 part of it (that are images returned as base64), I think I should use a destructured logger, is it right?
I've tried increasing the Seq limit to 1mb but the content is not saved even to log file so I think that's not the problem...I use Microsoft Logging (ILogger interface) with Serilog.AspnetCore
Is there a way I can handle such a scenario?
Thanks in advance
You can log a serialized value by using the # format option on the property name. For example,
Log.Information("Created {#User} on {Created}", exampleUser, DateTime.Now);
As you've noted it tends to be a bad idea unless you are certain that the value being serialized will always be small and simple.
Q1 - I have been reading through the docs for reCaptcha, and looking at many different forum cases but I am not experienced with API calls at all - I am trying to add a captcha to my custom contact form but I am stuck on the verification step trying to figure out how/where to send the info for verification, and how/where to receive it so I know weather or not the user is verified.
(Side Question: Why is it necessary to validate the token generated by the captcha? Isn't it good enough that you can tell weather or not the puzzle/answer was solved?)
Before the closing head tag:
<script src='https://www.google.com/recaptcha/api.js'></script>
End of my form:
<div class="g-recaptcha" data-sitekey="my-site-key"></div>
I can see the string/token generated by a correct answer when I call:
grecaptcha.getResponse();
Now (as I understand it) I have to verify this string/token which is where I get stuck:
URL: https://www.google.com/recaptcha/api/siteverify
METHOD: POST
DOCS: https://developers.google.com/recaptcha/docs/verify
I am relatively decent with jQuery and vanilla JS but when it comes to API calls I have almost no experience, which is why at this point in the docs I am unsure of how to 1 - form an/the API call (for verification), 2 - where to make the API call from template files-wise, 3 - how to get the response back, or rather how the response comes back.
As I mentioned I am using a Bigcommerce store, and the Google reCaptcha documentation mentioned in several different areas that this step is done on the server-side (or should be). I know that I am fairly restricted in the template files that I can modify - I can view and modify the HTML/CSS/JS files but I have no access to any PHP.
Any help or push in the right direction would be greatly appreciated - at this point I am going in circles finding and trying to read/follow the same docs (Google and other) and forum cases. Thank you.
Trying to answer your questions one by one.
Client side Captcha's are discussed here, please check and note that considering the power of Java Script, client side captchas are not safe.
How reCAPTCHA works: Once someone include below script, google will verify
user.
https://www.google.com/recaptcha/api.js
Writing below attributes in the Form will send data to google first and
response will be added in final post of the current Form with
attribute named g-recaptcha-response :
<div class="g-recaptcha" data-sitekey="your_site_key"></div>
How to validate reCAPTCHA One has to validate this g-recaptcha-response with google. [ NOTE: this is requried becaues
client can send any random value for attribute g-recaptcha-response
without going through Captcha ]
$verifyResponse =
file_get_contents('https://www.google.com/recaptcha/api/siteverify?
secret='.$YOUR_SECRET.'&response='.$_POST['g-recaptcha-response'])
/*allow_url_fopen must be ON if you want to use file_get_contents.
check it using phpinfo();*/
file_put_contents( "logfile", $verifyResponse, FILE_APPEND );
$responseData = json_decode($verifyResponse);
$register_result = 'Robot verification failed, please try again.';
if( $responseData->success )
{
$register_result = 'You are not a bot';
}
else $register_result = 'You are a bot.';
Captcha with HTML/JS/CSS reCaptcha will not work for you if you don't have PHP access.
Puzzles as Captcha Captcha Puzzles are also possible and such captcha's are also available but they are handled on server side.
The reCaptcha verification si to make sure that the answer you received does come from reCaptha server, that the user is not a robot, that it hasn't matured, and that it hasn't been used more than once.
All this is really important to the server running the app, more that the cliente showing the form in order to accept or reject the form to be processed.
This is why the validation has to be done on the server. The client is an unsecure environment that can be tricked so the server cannot trust it.
Besides, to do the validation you need a secret api key. As it is secret it can't be embeded into the client code.
If you don't have access to the php or cannot add and aditional php to do the validation, I don't think you can implement reCaptcha.
EDIT I
The bottom line is that client code (js, jQuery running in a browser) cannot be trusted to do any kind of validation from the server point of view.
For example suppose you implement an input element for the user to enter the result of the sum of two random integers between 0 and 9. Very simple.
In the javascript code in some place there is an:
if(a + b === c){
sendFormToServer();
}else{
reject();
}
Anyone using the browser's developer tools could bypass the "if" and directly call sendFormToServer(). And the server has no way of knowing it.
Hey guys this has been tripping me up quite a bit. So here is the general problem:
I am writing an application that requires users to enter their Summoner Names from league of legends. I do a pretty simple data scrape of a match and enter the data into my database. Unfortunately I am having some errors registering users with "special characters".
For this example I will use one problem user: RIÇK
As you can see RICK != RIÇK. So when I do the data scrub from the site I get the correct value which I push onto an array for later use.
Once I need the player names I pull from the array as follows: (player_names is the array)
#temp_player = User.find_by_username(player_names[i].to_s)
The problem is the users with any special characters are not being pulled. Should I not be using find_by? Is to_s changing my original values? I am really quite lost on what to do and would greatly appreciate any help / advice.
Thanks in advance,
Dan
I would like to thank Brian Kung for the link to the following: joelonsoftware.com/articles/Unicode.html It does a great job giving the bare minimum a programmer truly needs to understand.
For my particular issue I had used a HTML scraper to get the contents but which kept HTML entries throughout. When using these with my SQL lookups it was obvious that things were not being found. In order to fix this I used the HTMLEntities Gem to decode the text as follows (as soon as I put the into the array originally):
requires 'RubyGems' #without this cannot include htmlentries as a gem
requires 'HTMLEntries'
coder = HTMLEntries.new
line = '<'
player_names.push(coder.decode(line))
The Takeaway
When working with text and if running into errors I would strongly recommend tracing the strings you are working with to the origin and truly understanding what encoding is being used in each process. By doing this you can easily find where things are going wrong.
Tagsoup is interfering with input and formatting it incorrectly. For instance when we have the following markup
Text outside anchor
It is formatted as follows
Text outside anchor
This is a simple example but we have other issues as well. So we made tagsoup cleanup/formatting optional by adding an extra attribute to textarea control.
Here is the diff(https://github.com/binnyg/orbeon-forms/commit/044c29e32ce36e5b391abfc782ee44f0354bddd3).
Textarea would now look like this
<textarea skip-cleanmarkup="true" mediatype="text/html" />
Two questions
Is this the right approach?
If I provide a patch can it make it to orbeon codebase?
Thanks
BinnyG
Erik, Alex, et al
I think there are two questions here:
The first Concern is a question of Tag Soup and the clean up that happens OOTB: Empty tags are converted to singleton tags which when consumed/sent to the client browser as markup gets "fixed" by browsers like firefox but because of the loss of precision they do the wrong thing.
Turning off this clean up helps in this case but for this issue alone is not really the right answer because we it takes away a security feature and a well-formed markup feature... so there may need to be some adjustment to the handling of at least certain empty tags (other than turning them in to invalid singleton tags.)
All this brings us to the second concern which is do we always want those features in play? Our use-case says no. We want the user to be able to spit out whatever markup they want, invalid or not. We're not putting the form in an app that needs to protect the user from cross script coding, we're building a tool that lets users edit web pages -- hence we have turned off the clean-up.
But turning off cleanup wholesale? Well it's important that we can do it if that's what our usecase calls for but the implementation we have is all or nothing. It would be nice to be able to define strategies for cleanup. Make that function plug-able. For example:
* In the XML Config of the system define a "map" of config names to class names which implement the a given strategy. In the XForm Def the author would specify the name from the map.
If TagSoup transforms:
Text outside anchor
Into:
Text outside anchor
Wouldn't that be bug in TagSoup? If that was the case, then I'd say that it is better to fix this issue rather than disable TagSoup. But, it isn't a bug in TagSoup; here is what seems to be happening. Say the browsers sends the following to the client:
<a shape="rect"></a>After<br clear="none">
This goes through TagSoup, the result goes through the XSLT clean-up code, and the following is sent to the browser:
<a shape="rect"/>After<br clear="none"/>
The issue is on the browser, which transforms this into:
<a shape="rect">After</a><br clear="none"/>
The problem is that we serialize this as XML with Dom4jUtils.domToString(cleanedDocument), while it would be more prudent to serialize it as HTML. Here we could use the Saxon serializer. It is also used from HTMLSerializer. Maybe you can try changing this code to use it instead of using Dom4jUtils.domToString(). You'll let us know what you find when a get a chance to do that.
Binesh and I agree, if there is a bug it would be a good idea to address the issue closer to the root. But I think the specific issue he is only part of the matter.
We're thinking it would be best to have some kind of name-to-strategy mapping so that RTEs can call in the server-side processing that is right for them or the default if it's not specified.