I'm researching the Play Integrity API as a first step of migration from SafetyNet.
There is one log line that repeats in every flow, either successful or not:
PlayCore I UID: [10547] PID: [7783] IntegrityService : linkToDeath
Any idea what does it mean? I don't want to die yet, lol.
On a serious note: is someone experiences this ?
Related
I have a YouTube API Key, and I was testing it out when I started watching my [requests] through the dashboard?project=myproject-111111&duration=PT1H
The issue is this. I stopped using the key about 15 minutes ago, and that blasted thing is STILL counting. Since I stopped using it, it has gone from
9,875 -to- 39,978 (And still counting)
Why would this be still counting for? The key is NOT being used, but its counting.
You are allowed 1 million requests per 24 hour day. And at this rate, I will be there in no time flat.
I have tried to find an active Forum for the YouTube API, and there is none. The only ones I found had their last post in 2012 and 2014.
Any idea's why this thing is still counting? (46,333)
Updated 10:47 pm EST: On the [Quotas] page. It is over 300,000+ and counting. This is a blasted joke. I reported it in as a bug, but the bug reporting page, is so full of SPAM, that it makes you wonder on rather they are going to check it regularly or not.
Updated 10:51 pm EST: It finally stopped. Conflicting count returns are coming in from the different pages.
118,762 on the dashboard
415,489 on the YouTube Quotas page.
I went to the YouTube Developers Twitter page and tweeted to them about the issue, and am awaiting a reply back.
I will post here, once I get a reply back.
Is this a BUG?
Or, do other issue?
CodingEE
This is something that I was looking at. As quota is eaten up by api calls that the site is not actually making.
This is unfortunately something for Google to fix. I did send a request to look into it, but no reply.
The cause is "BOTS". They will search, index and run the page affectively to index and rate it. As such, the will incur api usage.
This can be reduced in a few ways.
1: If in testing stage, and you do not use the online version too often apart from testing updates to code, then you can remove the api key from the code while not testing.
2: If it is live and running, but you wish to stop the bots eating the quota, then in your Google dashboard, block the bots.
This will however stop indexing. So I would recommend "trying" to limit them and how often they inex.
Aside from that, we need to get Google to (if possible) not use quota for bots.
I'm using the VerificationController provided by Raywenderlich in several of my apps, and it's been fantastic. Totally reliable, easy to implement, and effective. It's been live in three of my apps for several months each.
However, two days ago, all three apps suddenly stopped working properly. Every purchase is now being flagged as invalid without exception, both for my live users and for my own test accounts. I've made no changes to the apps or their backends, in fact I've been moving apartments so I literally haven't touched them in a week or more. The change was instantaneous across all three apps, and I've understandably started getting complaints.
The problem seems to be in the checkReceiptSecurity() function (it's always returning NO when it needs to return YES for valid transactions), but the code inside that function is beyond my ability to comprehend. I'm hoping someone has encountered something like this, or perhaps is even experiencing it now, and knows a solution?
As far as I can tell, it seems to be happening on the second of these lines (VerificationController.m line 158).
require(signature_length > offsetof(struct signature_blob, certificate), outLabel);
require(signature_blob_ptr->version == 2, outLabel);
certificate_len = ntohl(signature_blob_ptr->cert_len);
Which are helpfully commented as "Make sure the signature blob is long enough to safely extract the version and cert_len fields, then perform a sanity check on the fields." When it hits the signature_blob_ptr line, it suddenly jumps to the end of the function, which I assume means that it failed a check having to do with the version number of some response from Apple?
Can anyone shed any light on what is happening? This is obviously devastating to my app portfolio, and I need to fix it immediately. I'll disable the verification temporarily and release an update if I have to, but I'd like to find a fix for whatever has changed...
Search for "receipt validation" at https://forums.developer.apple.com
Apparently, a certificate update just made VerificationController to stop working.
The obvious, but not quick at all, fix is to use the more recent receipt validation processing. See: https://developer.apple.com/library/ios/releasenotes/General/ValidateAppStoreReceipt/Introduction.html#//apple_ref/doc/uid/TP40010573-CH105-SW1
As for the code above, signature_blob_ptr->version == 3 now. But putting 3 instead of 2 in the code is not a fix as the signature is not 128 bytes long anymore.
I am having issues with Kimono Labs. Every scrape I run will run indefinitely without throwing an error or completing. Occasionally, the scrapes will randomly start working days in the future without any changes on my behalf - only to fail a few days later. I love Kimono because it is so easy to integrate with Google Sheets for friends to alter the data, but this has become problematic. There doesn't seems to be any related help in the Kimono help data for an issue such as this.
One of my scrapes is not behind a paywall and the other is. One is set to run daily and the one behind the paywall is set to run hourly.
What steps can I take to troubleshoot this error and get the ball rolling again?
I had a very simple API doing the exact same thing for weeks!
I'm only using a free account so I didn't have any support but I ended up sending a bug report at https://www.kimonolabs.com/support .
Strangely enough, the very next day, the API started working normally again (and has ever since). I assume they looked into it and fixed whatever was stopping my crawl from completing.
I'm trying to write a program to ask me to input some information periodically, so I've written a service in C to run in the background, I can watch it reporting its okay by refreshing its log file. Now I'm stuck on how to get it to open up cmd and ask for the information.
I'd like to save this information to a log file. (I'm planning on monitoring my sleeping habits)
I tried using system("getinput.exe") and that seems to do nothing, I know using system() is bad but it was a first step.
CreateProcess() I simply cannot get to work, the example on MSDN http://msdn.microsoft.com/en-us/library/ms682512.aspx doesn't work for me, i just get CreateProcess failed (2) whenever i try createprocess.exe dir for example.
Surely there must be a way?
EDIT: Thanks for the replies I will try to take a different approach then. Where would I start with writing a background application that can occasionally ask for user input in C?
I've got a web application that, for performance reasons, throws any data sent into a logfile.
I've got two concerns with this approach:
How do I best rotate logs, in order to not lose data?
For each user session multiple requests are logged. Each request has a unique id so there is an easy way for me to tie the requests to the session. The problem is, however, that if I rotate the logs I risk ending up with one request in one log and another request in another log.
How do I arrange my parsing in a way that allows me to parse all requests from a given session? I am willing to define a session timelimit, for example that the requests must, at maximum be 30 minutes apart.
If I had a hourly log rotation at 00 minutes:
What if the user made one request at 13:59 and one at 14:01 - The user would end up having requests in two different logs.
Answer to part 1: If you're on *nix, use syslog/logger. Check the logger(1) and syslog.conf(5) man pages.
Answer to part 2: You're not forced to look at just one log file at a time. less ${SERVICE}* will normally open all the relevant log files together: when you get to the bottom of a page, :n will move you to the next file and :p back.
Alternatively, use a log analyser program. Steve Kemp's post on promptly finding needles in syslog haystacks covers, together with its comments, a lot of ground.