I want to build a system where a document is to be signed by the user. It may be the case that user takes 10 days to sign the document or even in minutes things are done.
Using Remote signing : User will receive the mail from third party app, and the validity of that signing link is long like 10-15 days.
Using Embedded signing : User will have to sign the document within minutes. No mail is received from 3rd party app.
I want to have a hybrid kind of system, where our system should send the mail containing the signing link to user and that link should be valid for 10-15 days.
There are workarounds for my use requirements. But I want a robust and proper solution for this.
All of the above is easily achievable with the HelloSign API. In both cases the signing link is generated right when the user launches the document to sign so there's no risk for it to expire.
Non-embedded signing: with one API call, HelloSign will send an email to the user with the link to launch the document, an email reminder if the user takes long to sign, and an email with the link to download the final document once signed. The link the user gets can only expire if the document is manually marked as cancelled (or declined by the user).
Embedded signing: in 3 API calls you are able to create the document, generate the link for the document once the signer is ready to sign in your workflow, and download the completed document for you and the user. The API uses webhooks to inform you of events during the document lifecycle, and you have the ability to handle all notifications to the user as well as the timing for each API call.
Hope this helps! Let know if you'd like me to expand on the above.
You want your app to send the email and control the validity time for the link. You also, it appears, want to use embedded signing. All of the above is straight forward with DocuSign. See my prior answer on how to create long lived embedded signing links.
[I work for DocuSign]
Re: embed UI in our app?
You can update your app to iFrame DocuSign's Signing Ceremony, redirect to it, or open a new browser tab for the signing ceremony.
iFraming is not recommended since it does not enable signers to assure themselves that they're using DocuSign. If you do use an iFrame, the DocuSign Signing Ceremony must receive 100% of the width and height to provide the best signing experience (especially on mobiles).
You can brand the DocuSign signing ceremony to include your app's logo and match your app's colors, fonts, etc.
Related
My server receives a real-time developer notifications (RTDN) from Google Play. Now what?
How to check whether RTDN by Google Play comes from Google, not from a hacker? Suppose I use purchases.products.get API to check it. Then a hacker could send me repeated RTDN, what would lead my server into thinking that purchase happened two times (when it was really one time).
I want my server to top the user account on every purchase from my app. I want the amount of purchase to be arbitrary (specified by the user). Should I include the amount in dollars into product productId/SKU like: credit-$0.78?
Also, it is unclear how to determine the installation ID of the app (a UUID I store in app data on installation) for which the purchase was done. Should I include the UUID in productId/SKU?
Quoting https://developer.android.com/google/play/billing/security
A special case of sensitive data and logic that should be handled in the backend is purchase verification. After a user has made a purchase, you should do the following:
Send the corresponding purchaseToken to your backend. This means that you should maintain a record of all purchaseToken values for all purchases.
Verify that the purchaseToken value for the current purchase does not match any previous purchaseToken values. purchaseToken is globally unique, so you can safely use this value as a primary key in your database.
Use the Purchases.products:get or Purchases.subscriptionsv2:get endpoints in the Google Play Developer API to verify with Google that the purchase is legitimate.
If the purchase is legitimate and has not been used in the past, you can then safely grant entitlement to the in-app item or subscription.
[skipping about verification of subscriptions]
Real-time developer notifications (RTDN) is a mechanism to receive notifications from Google whenever there is a change in a user's entitlement within your app. RTDN leverages the use of Google Cloud Pub/Sub which is encoded and secure, each publish made to a Cloud Pub/Sub topic contains a single base64-encoded data field.
Note: You must call the Google Play Developer API after receiving Real-time developer notifications to get the complete status and update your own backend state. These notifications tell you only that the purchase state changed. They do not give you complete information about the purchase.
The Google Play Developer API is a server-to-server API that complements the Google Play Billing Library on Android. This API provides functionality not available in the Google Play Billing Library, such as securely verifying purchases and issuing refunds to your users.
We have received a notice from Google Play that our app will be removed if we do not provide them with login credentials in our app. The problem is that our app is a second-screen game, where the primary screen is a desktop game which provides a four digit code for people to enter in our app and log on to the game. Our app has been in the Play Store for years and is quite popular.
Google Play has given us until Oct 4th to provide them with a code, otherwise our app "may be removed from the Play Store". We have set up a desktop computer running games in loop 24-7 until they have reviewed our app, and we have provided them with a link to a twitch stream where the game runs in loop.
It's now been seven days and we have not heard anything from Google Play. It's very frustrating that there is no personal contact, we only receive auto-generated bot/AI mails about policy violation.
Does anyone know what further action we can take to make sure our app is not removed? We have "contacted support", although contacting support in Google Play means just writing your app name and email address in a form and selecting a radio button of what the problem seems to be (none of them apply exactly). No response for days.
This is the original warning mail from Google Play:
Hi Developers at xxx, After a recent review, we’ve identified that we
need additional information about your app xxx in accordance with our
policies. Please resolve the issue described below by October 04, 2022
to avoid further action against your app. Reasons of violation Issue:
Need login credentials for app review In order for us to review your
app for compliance with Developer Program Policies, we will need you
to provide valid login credentials for your app. If users need
credentials to access your app, please provide all appropriate
credentials via Play Console. If you previously supplied credentials,
please ensure that they have not expired. If your app normally uses
2-Step Verification (e.g. SMS verification), biometrics (e.g. a
fingerprint or face scan) or a location-dependent password (e.g.
geo-gate), please provide valid demo credentials that we can use
instead.
in Google Play Console in app content > app access > Add new instructions
in password field write down the 4-digit code.
in Any other instructions Write a detailed step-by-step guide on how to walk through game until the 4-digit code entered, and provide them with a valid digit code (that always works) and write that this is a "Demo Digit code".
Also, provide them with a video just to the point of entering the code and logging in (the shorter the video the better)
And you will have to wait, it takes a lot of time do not worry.
I was testing functionality on a website that I'm developing that allows the user to sign in using their Google account. I filled in the "OAuth consent screen" in the Google Developer's Console, including all of the URLs to allow Google to redirect a user back to my website with the necessary OpenID information. Everything works, but I used test URLs on the "OAuth consent screen". Afterwards, I made the very costly mistake of clicking the button at the bottom of the screen labeled Submit for verification. I should have clicked the button labeled Save. The URLs on my OAuth consent screen all have internal hostnames, so they're not accessible from the Internet. Is there any way that I can cancel the request to Google for verification? The page is currently frozen, and it won't let me change any of the URLs until I inevitably fail the verification process. There is also a message that states that verification may take up to 4-6 weeks, which is a long time to wait for something with a known outcome...
I know this may not be the right forum for this question. However, Google's own support page links to StackOverflow, and I'm sure web developers must encounter this problem quite frequently. I tried looking on Google's FAQ pages, but didn't see anything about canceling the verification process. It's quite possible that I missed something....
Edit I've received an e-mail from the Google Cloud Platform notifying me that my request to have my app verified has been denied. This makes sense, since I completed the Consent form with incorrect test URLs. However, the Save button on the OAuth consent screen is still disabled. The screen appears to be in the verification process. Perhaps this is the intended workflow for the screen. At any rate, the original request for verification was denied within a day or two, which was quite fast considering the 4-6 weeks that Google allows for the process. If anyone can confirm or deny that this is the intended behavior of the OAuth consent screen, I would be happy to mark their answer as correct...
At this point, I'm inclined to believe that this is the intended behavior of the OAuth consent screen. 3 days after the verification request has been declined, the message Your consent screen is being verified. This may take up to several weeks. Your last approved consent screen is still in use. is still being displayed. I now believe that further changes to the screen, such as updating the URLs, will require the verification process to be restarted, since the Save button remains disabled.
I built a Chrome Extension using the Google Slides API ~8 months ago, with users having to sign in with the OAuth consent screen as to be able to use the extension. The extension has over a thousand users, and for the past weeks I've had reports of people seeing an error that says "Sign in with Google temporarily disabled for this app".
I checked and indeed the OAuth page was still "being verified", although it still said it would only take a few days / several weeks. I'm not using any sensitive scopes either, so it all seems very odd. If the app didn't meet the criteria I would have been rejected, but that doesn't seem to be the case.
So my question is, how can I get it verified, or if anything rejected so that I can make a new submission? I looked all over the place and I haven't found a way to get it unstuck. I'm pretty sure 8 months for verification isn't normal whatsoever.
Google seems to manually validate each OAuth screen. That's a long (and costly process), but to my experience, it generally takes 24 hours if you don't use any sensitive/restrictive scopes. As it's your case apparently, I presume your submission has probably being lost somewhere.
My recommendations:
Check in the Google Cloud Console the status of your OAuth Screen. After logged in Google Cloud console, click on the hamburger icon and select "APIs & Services" > "OAuth consent screen". At the top of the page you will see the status. If it's something like "pending verification", go to step 2. Otherwise, make sure the form is completed and submit it to verification again.
Search in your emails if you have been contacted by "api-oauth-dev-verification-reply [at] google [dot] com" (the address might slightly change as they use a ticketing solution). Maybe they tried to contact you but the email went to spam?
Get in touch with the OAuth team by emailing "api-oauth-dev-verification-reply [at] google [dot] com". Make sure to add your
Google Project number in your email, so they will be able to check
what's wrong.
Disclaimer: I don't work at Google. But I'm bit familiar with that process now :)
What I want to build:
I want to build a website where users can connect their google calendars (this will use Google Calendar API's)
and view their calendar events, as well as edit them, and create new ones.
My problem:
In order to do so, google says my app needs to be verified, which can take weeks, and I also need to set up terms of services pages, privacy policy pages
I also need to supply authorised javascript origins which MUST start with https, which of course is a problem during development, since my origin is http://localhost
I also need to set up support emails and homepage link
Question
I just want to start building my application without having to set up a whole production-ready website eco system.
Is there anyway I can use these Google Calendar APIs for editing/creating calendar events locally, without having to set up everything mentioned above first?
Unverified apps can still be used by the developer who created the project on google developer console.
Unverified app screen
The app or script might display an "unverified app" screen before it displays the consent screen. This is based on the specific scopes that your app includes in the request.
You can still work on your app while you are going though the verification process. However that being said i would start that process asap it can take a long time to get verified.
Yes, you can. As far as I am able to tell, all the verification step does is remove the "unverified app" screen. As long as you click Advanced > Go To ... (unsafe), you should be able to create and edit calendar events for that user in your application.
In order to be able to create and edit calendar events, you need to use the most sensitive scope, which is https://www.googleapis.com/auth/calendar. I couldn't figure out how to edit and create calendar events in my web app until I changed my scope from calendar.events to calendar.
Creating Events: https://developers.google.com/calendar/create-events