I have code that generates .ICS scheduling information customized for people and each is saved to the server. A link is displayed on the frontend which just displays the custom link (along with information on how to sync using Outlook, Google Calendar or Apple iCal).
Everything is working okay so far, Google Calendar seems to refresh consistently, Outlook is a bit of a pain but there are workarounds. When I went to test on an iPad and tried to 'Add a Subscribed Calendar', it keeps saying that it couldn't connect using SSL
I'm not too entrenched in the Apple ecosystem at this point, is it an SSL thing with Apple products where you have to authenticate or need a valid SSL certificate to access the .ICS file?
Thanks for any considerations
Related
We have a mobile app and our users got a
"sign in with google temporarily disabled for this app"
When they tried to login their YouTube account with iOS (There's no problem with Android devices).
We submitted a verification request long time ago, and we got from YouTube an email (May 26th 2020),(May 26th 2020):
"Hi Adam,
Thanks for working with us on the YouTube API Services compliance review. We have completed your review and do not require any further actions from you at this time.
We may reach out again to re-review your API Client for compliance with YouTube API Services Terms and Policies.
We appreciate your time working with us on this and please continue to comply with the YouTube API Services Terms and Policies."
Since then, nothing had changed and our app hasn't been verified yet, and our users can't connect with their youtube accounts.
What can we do? We are just waiting and we don't even know how to contact YouTube and ask about our specific case/project.
Thanks you,
Adam.
sign in with google temporarily disabled for this app
Means that your application has not been verified by google. You need to go through the verification process.
You can use a project for development without verification. However there are some limitations (more information here). Basically, you have now reached the limit of 100 users accessing the application.
If you still havent heard anything from google after they say they have verified your application I think the only thing you can do is to submit it again and double check that you are using a client that was created under the project that you requested verification for there's really nothing else you can do.
I’m working on an add-in for Microsoft Outlook, and we need to provide our users with direct links to specific emails. We’ve been using the webLink property of the message object: https://learn.microsoft.com/en-us/graph/api/resources/message?view=graph-rest-1.0
At some point recently, it appears that these web links have stopped working for outlook.com users. Instead of opening up to the email, the page will either appear to load forever or show a page saying “Get Outlook on your phone for free” with a form to submit a phone number to receive an Outlook mobile app download link via text. These web links still work for all the Office 365 accounts we have tested.
Whether we fetch a message and its web link using the REST API V2 or the Graph API, we get the same web link that will not work for outlook.com accounts.
It looks like we’ve been seeing the same behavior described in this question: Outlook weblink does not always correctly open the mail
Is this a known issue, and if so are there any known workarounds? Thank you.
Is this the same issue on GitHub: https://github.com/OfficeDev/office-js/issues/1095
The fix for that is being worked on.
We are facing the below screen when trying to authenticate to Google. The app that we are trying to authenticate is used for internal development and we did not publish it to our users.
Any idea why this occurs?
We faced an Unverified App screen before (as below) but now the authentication is disabled.
OAuth Client Verification
Starting July 18, 2017, Google OAuth clients that request certain sensitive OAuth scopes will be subject to review by Google.
OAuth Client Verification
Starting July 18, 2017, Google OAuth clients that request certain sensitive OAuth scopes will be subject to review by Google.
Review is not required if you are only using it under the same account as created the project in Google Developer console. You can read more about this change in this help center article.
This change applies to Google OAuth web clients, including those used by all Apps Script projects. By verifying your app with Google, you can remove the unverified app screen from your authorization flow and give your users confidence that your app is non-malicious.
Once you have applied for verification it takes around a week and it should start working.
I found this thread some time ago when this happened to us in our development project on Google Cloud Platform.
You can use a project for development without verification. No problem on that. But there are some limitations (more information here and here). Basically, we reached the limit of 100 users accessing the application. It was strange because we were testing with few accounts (5-6) until we found that, if you uninstall and install the application again, it counts as a new user. We were testing incremental authorization, so we uninstalled/installed the application a lot of times and we reached the quota.
When you reach this limit, you will see the message "Sign in with Google temporarily disabled for this app" and only users from the organization where the project is hosted can access the application. So we couldn't make test with our accounts from a demo domain or our Gmail accounts.
The only solution available was to pass the OAuth verification form (even if you didn't want to publish the application), but there were problems to do it. For example, it was mandatory to remove http://localhost from valid OAuth URLs. And more problems related with development.
❗ But this has changed recently. I have accessed to OAuth credentials screen in Google Cloud Platform (APIs & Services > Credentials > OAuth consent screen) during this week and now the page it's different. Now you don't need to specify "Authorised JavaScript origins" and "Authorised redirect URIs", you just need to specify your scopes for Google APIs and the Authorised domains. Then, at the bottom of the page you will find the button "Submit Verification" and the process will start. You will also find some information on the right:
About the consent screen
The consent screen tells your users who is requesting access to their data and what kind of data you're asking to
access.
OAuth Developer Verification
To protect you and your users, your
consent screen may need to be verified by Google. Without
verification, your users will see an additional page indicating that
your app is not verified by Google.
Verification is required if
Your application type is public, and You
add a sensitive scope Verification may take several days to complete.
You will receive email updates as it's processed.
Saving without publishing
Even though your consent screen is
unpublished, you can still test your application with users with the
following limitations:
Sensitive scopes are limited to 100 grant requests before verification
is required
Users see an additional page indicating that your app is
not verified by Google.
To include "Authorised Javascript Origins" and Authorised redirect URIs" you need to go to APIs & Services > Credentials and there click on your OAuth 2.0 client ID. There will be a form where you can add them.
In our case it took 1 day to get a response from Google. In the email there were some instructions to pass the verification. We had to reply the email with a video uploaded on YouTube addressing the following points:
How does user sign-up on your app and grants access to the sensitive scopes requested in verification?
OAuth consent screen as seen by end users
How does your application use the requested scopes to provide services to developers?
A test account email and the password for us to test the user sign-up process and validate the project's functionality.
We recorded a video showing points 1, 2 and 3 and sent them a test account for number 4.
After 1 day, we got another response from Google confirming that our project had been verified.
So finally the problem was solved! 🙂
I hope this could help people in the same situation. It was really annoying for us.
I had to go into my Google Apps Script settings and turn on the "Google Apps Script API" setting. Then I tried again, and the script executed correctly without issue.
I had used the script a couple of weeks ago and it worked fine, so something must have happened between then and now that changed it... Not sure what caused that setting to switch.
I'm creating a simple iPhone app. The basic premise is that the app will display some data (That I provide online) on the application. The data changes over time, so the app has to draw the data from online and display it. I don't have a significant programming background so I don't want to use my own server.
Thus, I thought it would be significantly easier to just put the data into some documents on a Google account and then access them programmatically via the Google Drive API. I could then update the data in my Drive account and it would get updated in the application. The key here is that I am ONLY accessing ONE account that I own MYSELF. The users' accounts are not being accessed. Therefore the goal is to never have to log in manually. It should all happen behind the scenes, aka, it should look like a server, not a google doc.
With this in mind, it doesn't make sense to show the Google Accounts sign-in page to my users as the standard OAuth2.0 tutorial shows here:https://developers.google.com/drive/quickstart-ios#step_1_enable_the_drive_api
I should be able to access my own data by somehow hardcoding in my username, password etc. Google agrees here: https://developers.google.com/drive/service-accounts#use_regular_google_accounts_as_application-owned_accounts
The above link mentions a "refresh token" that I'm supposed to save. However, I have no idea how to build and save that token, or even for that matter, where to find it.
I've gone through both the basic tutorial and the Dr. Edit Tutorial for iOS, but they both assume that the application is accessing USER accounts not application-owned accounts.
I'm not asking for someone to write the code for me (though tidbits are nice), but if you can point me to a step-by-step guide or related sample code that would help me get started that would be awesome. I'll even come back and post the code that I use!
EDIT: Since I realized that the Google Drive API wasn't something I could use for what I am trying to do, I eventually found Parse which is an awesome tool that handles all the server backend for me and is free at the basic level.
Google APIs objective-C client library doesn't support service (application-owned) accounts, because they are supposed to be used by a server-side apps, instead of clients -- you shouldn't be distributing your private key as a part of an app.
If you would like to distribute content from a service account, maybe you should write a server leg to do the authentication and pass clients credentials in a secure way for them to talk to the API on the behalf of the service account. Or, use Web publishing to make documents universally accessible without authorization and authentication if privacy is not a concern.
I have a mobile web app/site and I would like the users to upload a word document to our site.
As safari on the iPhone is not able to upload files what are the alternatives?
I have seen http://code.google.com/p/iphone-photo-picker/ however this is not photograph.
Is it documented anywhere that the Dropbox API, iCloud API or another API would allow selection a file from a user to copy to our servers?
Alternately is there another way for our iPhone users using safari?
No, iPhone does not offer input type file on it's browser (except for images or videos).
What i do is, have users to send file(s) via email to site and download it programmatically on the server side and assign it to user's account either according to email address or some sort of password in the email.
Investigation has shown that the drop box API for the user so select a via on the webpage using OAuth could be an option in the future.
However the dropbox api documentation at the time of writing says:
Web applications using the Dropbox API are currently not officially
supported.
iCloud API is in beta and only available to members of the iOS and Mac Developer Programs so I am unable to review it's possibilities.
Update: I have now found this site: http://filepicker.io that handles uploads from facebook and dropbox.