We have a WordPress plugin with an Authorize.NET AIM/ARB integration. It's pretty old. We setup subscriptions with ARB, process the initial payment with AIM, and then listen for Silent Posts to know when subscription rebills occur.
Authorize.NET Silent Posts can have an SHA2 Hash to check integrity, using a Signature Key. We support this. Everything has been working fine for years. Then recently, I fielded a complaint that rebills weren't being logged, and I traced this to the absence of the SHA2 hash in the Silent Posts. This is happening both on my dev site using sandbox, and in at least one production instance.
My understanding is that once a Signature Key has been generated on an Auth.NET account, the x_SHA2_Hash parameter should be populated for all Silent Posts. I had generated a key, and in years past everything worked fine, but at this point, no Silent Post contained a value for x_SHA2_Hash.
I regenerated my Signature Key in sandbox, this caused x_SHA2_Hash to be populated in the Silent Post for initial payments, but not for rebills, even on newly-created subscriptions. So I have a few questions:
Can anyone with ARB subscriptions and a Signature Key configured confirm that the Silent Posts are still returning a value for the x_SHA2_Hash parameter on their accounts?
Is anyone aware of a change to expected behavior of Silent Posts since 2019?
Is expected behavior different in sandbox and production?
Anything I need to do, either in the Auth.NET account, or in the XML I send to create the ARB subscription, to reenable the SHA2 hash in Silent Posts for rebills?
Related
I'm developing a webapp which allows users to log in with their Google accounts, using OAuth2.0.
I've created an OAuth2.0 client ID, configured the OAuth consent screen with the Publishing status set to 'Testing', and added a test user.
The frontend of my app is built with React, and I'm using a package (react-google-login) to handle the flow. I can successfully sign in with the Google account I added as a test user, and retrieve the basic profile information needed.
The problem is I can also sign in with other Google accounts, which have not been added to the list of test users. I imagine that Google should simply not issue access tokens for accounts which are not in the list of test users.
I feel like I've misunderstood something about the OAuth process, or I have configured something incorrectly. I would appreciate if anyone had any pointers?
Thanks.
It is indeed bugged.
I was in the same spot as you, assuming I had misunderstood something. After reviewing my code over and over with no luck, I made a Stack Overflow post, in which I was advised to post to Google's bug tracking system. After doing some troubleshooting with Google they confirmed the bug, and they are now working to fix it (for a little while already).
I included this thread as an example when talking to Google. I meant to post an update here after getting in touch with them, but I forgot, sorry!
The buganizer thread with more details:
https://issuetracker.google.com/issues/211370835
Is it possible you're only asking for the email scope?
It appears the test user filter and possibly the whole concept of the 'app' being in test mode exists only inside the consent screen feature.
For some reason, Google doesn't show the consent screen if you only ask for email.
So... maybe that means you don't need a consent screen, and therefore don't need to care what that feature thinks about your app (that your app is in test mode and needs to be verified before going into production).
Or maybe it's a bug? Or maybe just because you can do this doesn't mean it's allowed by Google's terms. Maybe they just haven't implemented preventing that use case.
Anyway, it may help you to know that if you add a more significant scope like the Calendar API then the following things will change:
Non-test users will get a message like "The developer hasn’t given you access to this app." and won't be able to complete oauth
Test users will get a message like "Google hasn't verified this app"
Test users will see a consent screen
Basically, everything starts working as expected.
By the way, just putting "email" or "profile" for scope seems to be an old way of doing things, and all the newer scopes want you to use a full URL for the scope (despite google themselves not using the full URL when you're configuring your scopes).
For example, if you want the email and calendar scopes, you can put this value for your scope field:
email https://www.googleapis.com/auth/calendar
Or you can use this equivalent value:
https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/calendar
Not suggesting you add a scope like email for the sake of it, just that it sheds light on what's happening, and if there's a scope like that that you need anyway, adding it will solve your problem.
I have two applications which have a different server and using one authorize.net account. I have to put two silent URL in the one authorize.net account. how can i do it ?
You can't have more than one Silent Post URL. In fact, you probably shouldn't be using the same Authorize.Net and merchant account for different sites, but that's on you if you get caught.
You will need to make your Silent Post code smart enough to know which site the payment applies to and then act accordingly. This would probably mean utilizing the description field in the transaction to identify which site it came from. Then your code and use that to determine the originating site and perform whatever actions are necessary.
You also may want to look into Webhooks which offers more flexibility than Silent Post although it is more complicated to implement.
I'm receiving reports of several users running into issues with a django-registration sign up flow. I'm not able to reproduce it, and I believe it's just happening for certain browsers.
The problem happens when they follow the email activation link. Although the database shows they have successfully activated their email, they see the page that says that the link has expired. It's as if they visited the activation page already and then are seeing it for the second time. Initially I thought this was user error, but several users have reported it, which makes me think there is something else up.
One user has reported it working in Firefox, but not Safari, on a desktop - and not working on iPad or iPhone.
I have used django-registration a lot so I'm surprised by this bug and am drawing blanks about what it might be down to. Anyone have any ideas?
PS This is also happening with the same site, perhaps related: Django messages faulty, but only on one particular network
BUMP: This is not a dead request. I'm still hoping to get a solid answer from someone at Facebook or anyone else. Thanks.
Revised Inquiry: I don't know if I'm not asking the right question, or if I'm asking a valid question that no one can answer.
New Questions:
Can we use FQL or another means to get all of the requests seen at reqs.php? I'm essentially looking for something like this:
SELECT request_id, app_id FROM apprequest WHERE recipient_uid = me()
Notifications return that data but app requests are often batched into a single record with a link identifying some but not all requests. I want individual records for all app requests currently open. The data to do this must be available, as this is the data used to build notifications! It just seems that this is not being made available to us. :(
Thanks!
Original Inquiry Follows:
I have an app that aggregates various sources of Facebook information for a user. One of the sets of data I'm working on is the collection of apprequests which have been sent to this user by friends. For example, I open GreatApp and click to send a request to you. You may or may not use GreatApp but let's assume you haven't blocked requests from it. You now open my AggregatorApp that shows my request to you, and the included link back to GreatApp. The data you see is the same as at reqs.php but formatted differently, with much more data, and of course simply much better. ;)
I thought that is what we got in apprequests. From this question I'm understanding that apprequests is a collection of requests sent out by the current application.
When using path/me/apprequests, we don't need to specify an app ID. But I believe here we do need to provide an app token rather than a user token. Is that correct? If that's correct then this confirms that the requests are those that this app sent out, not requests generated by other apps.
When using FQL, we need to identify the uid of the app as well as the id of the request in order to query the apprequests table. I get that, but even with a valid request id and app id (and valid permissions) FQL doesn't return request data. (I haven't checked with an app id, maybe that's the key.)
I am hoping people will provide some concrete examples for any of the above, specifically getting inbound requests from other apps, and confirmation about what token or other detail is expected for /apprequests and the apprequests table to return data.
Thanks!
Other threads asking the same question without a good (or any) response:
thread1 thread2
You need to make a graph api request to get the apprequests connection for a user. See the current documentation here: http://developers.facebook.com/docs/reference/api/user/.
In the Connections table, the documentation correctly notes that you need an application access token to retrive the requests to that user. There's a bug in the documentation under (http://developers.facebook.com/docs/reference/api/user/#apprequests) that claims you need a user access token. This is incorrect, and (as you've seen) will return an empty list of requests.
Requests sent by an application are only visible to the application. The user can't see or delete these requests (though they are able to hide the request). The reason for this is that the applications can put data into the requests (255 characters) that's never exposed to the user or other applications.
I don't think there's a way you'll be able to aggregate a user's requests from apps that you don't have an access token for.
What I have found out (before my question was deleted) was that you can't access requests with a user token, and app tokens can only access requests that app has sent (and I found that out myself in the documentation and playing with the graph explorer). Since I know there are iPhone apps and browser plugins for processing requests, I assume they are accessing the page itself and parsing the data (like scraping a site). The downfall to that approach is that on the request page only around 100 requests from each app are shown at one time.
(Unless some people have found a way that they aren't sharing...)
You are right, you need the app_access_token and not the user_access_token.
I think the FB documentation has an error.
The definitive answer was provided by a Facebook developer here in response to my bug report. The resolution is that this is By Design. This relates to the note by #noah-callaway that there's probably some app-specific data in requests that should not be available to other apps.
This is a shame, in my opinion, because as Facebook is all about sharing data among friends, I think it adds a dimension to the ecosystem when apps can share (limited and reasonable) information among one another.
Thanks for the responses!
I've a forum where anonymous is allowed to post, protected by CAPTCHA. For users convenience, I set a Cookie for such a user which lasts about a month so the user does not get the CAPTCHA over and over again. In the simplest form the cookie is called no_captcha_for_one_month and it's value is 1. When the user returns and posts anonymously, he gets not CAPTCHA.
Anyone seeing the flaw? A forum spammer just needs to fill out the CAPTCHA correctly once and use the cookie information for his bot and there he goes.
I thought about getting creative and using a server-side hash which includes e.g. users IP address and some secret salt to generate the cookie value, but it would still be valid for this IP address, of course.
Someone I get the impression the question is silly and I try to solve something unsolvable.
I would recommend implementing your cookie value + salt implementation not to solve your problem but for security reasons. As explained by this blog post wordpress had a similar, albeit it much more severe, problem due to poor cookie security. In your case a determined spammer could always bypass your CAPTCHA even if the cookie had expired.
In order to solve the proposed problem the only solution that is coming to my mind would be to implement a Forced CAPTCHA algorithm that would override your newly secured cookie if it felt the user was being spammy. Off the top of my head I would use attributes like time since last post, number of posts today, the length of time it took to compose the message on the form, etc.
Edit: I should also mention that you can make your forum less attractive to spammers in the first place by implementing the rel="nofollow" attribute on user submitted links. See Wikipedia.
with such a solution it is always possible to use the cookie for a bot. no matter what you try.
As said below, a cookie can easily be taken from a browser and pasted in a bot code, so the solution isn't robust.
Other solutions:
Find some users posting a lot in the forum and ask them if they are volunteer to be moderator. A forum like the AutoHotkey one uses this system, and this works fine. Spammers tend to avoid active forums where moderation is fast and efficient. They prefer dead forums...
Limit the number of anonymous posts per IP address. Can be annoying for users, but can avoid spam flooding. Should be set up only if you experience such flooding.
Even worse, because you are using a cookie, the spammer doesn't even need to do the CAPTCHA once. Cookies can be changed by the client, they are sent by the browser with the page request, so the client can send whatever it wants. In fact spam requests would come from a script, so it's even easier to fabricate the cookies.
Storing the variable server side sill solve the problem I've mentioned; You set a random hash as the cookie, and have a table that stores the CAPTCHA status on the server. For the spammer to get no CAPTCHA, they would have to guess a hash that has the correct variable stored server side, shich is very hard to do.
The problem you mentioned; the fact that once a month might not be long enough to deter a spammer, you can't get around that. You have to show a CAPTCHA to every real user, as often as you want the spammer to enter one as well. Remember, a CAPTCHA is necessary because you can't tell a spammer from a normal user.
You should have the CAPTCHA show often, it will convince people to sign up anyway.
Encrypt the time (in pico or nano seconds) set it as a input value () & set it in your DataBase with a column name 'hash'
set that in every page & see if it matches the DB.