phw198
commented
9 months ago Your issue should be covered in the wiki.
Closed newtonrs closed 7 months ago
phw198
commented
9 months ago Your issue should be covered in the wiki.
newtonrs
commented
9 months ago I don’t utilize Chrome as my default browser, I use Firefox. The issue is perhaps the same, but I could tell you as a fact that it is.
Additionally, the connection attempt is not to secured (SSL) HTTP. So, again, not really a match as stated in the Wiki; though it may indeed be the same issue.
The real question though is, what effect is there if http: // localhost:55661 (http: // 127.0.0.1:55661) if it can’t be reached? Any?
What is the specific purpose of opening this port on local host? How important is it to successfully make this connection for OGCS to function properly, and continually? Specifically, is a failure to reach the port on “localhost” possibly why Google terminated the authorization for the app; forcing me to re-authorize (thank goodness I was able to just had to go through the disconnect and reconnect processes and not have to create a new project from scratch).
I appreciate any further information beyond the Wiki you can provide to enlighten this situation regarding accessing the port 55661 on localhost with respect to the proper functioning of OGCS and Google’s calendar as an OAuth2.0 registered application.
Thanks, Rick Newton.
phw198
commented
8 months ago I don’t utilize Chrome as my default browser, I use Firefox.
Does it make any difference if you change the default browser to Chrome? It is the browser after all that is interpreting the callback URL and you mention you have browser extensions installed - do any of them perform as some sort of middle man proxy (eg FoxyProxy) or a packet sniffer (eg BurpSuite) that will also be listening on localhost?
You also say you are using your own project, so worth reading through this SO article to check if you created the project credential correctly.
I suggest you narrow down the issue by reverting to the default OGCS authentication (not your own project API keys) and Chrome as the default brower without extensions enabled, and if that works, change one configuration item at a time until you locate the issue.
Ultimately the random callback port is automatically generated by the Google OAuth .Net library in order to return the access token; it's not something custom that OGCS is doing. TBH, I'm surprised you're saying OGCS is working at all if this step fails.
Specifically, is a failure to reach the port on “localhost” possibly why Google terminated the authorization for the app
I think there are many reasons your access token might be revoked/invalidated, eg. reconfiguring the project config, changing your Google password, Google believing there is suspicious activity etc.... I don't think the failed callback URL will invalidate an existing access token, no.
phw198
commented
8 months ago Copied @newtonrs's comment from https://github.com/phw198/OutlookGoogleCalendarSync/issues/1664#issuecomment-1922750370
Hi Paul,
I’ll try to reply to both your messages here together…
Regarding the switch to Chrome; that made no difference. The port must be blocked, but how when the AV software has been suspended, I do not know—I’m not uninstalling it to test that the AV software is the issue here.
The “project” is configured per the instructions you made available through GitHub—and seems to closely parallel the information at the link you provided—so, I’m fairly certain that the process was completed correctly. In addition OGCS was functioning and then stopped—perhaps the issue you indicate that Google was experiencing?—and so I tried using the credentials that already existed to reconnect, after disconnecting, the calendar. Again, this failed several times, so I decided to create a new “project” following the same steps as have been outlined. The original project and the new project appeared the same in setup and each had associated with it its own client ID and secret.
The new client/secret worked for approximately one month and then OGCS stopped working and then the message about the project “expiry” and no longer being valid. I then attempted to disconnect and reconnect with the previous project—the original project—and the message was the same: expired.
I deleted these two projects and started from scratch… This time around the project would not properly complete the configuration with OGCS, as per the posting and our “conversation” here about this issue. Finally, I disable all extensions to Firefox and the process completed to “register” OGCS with the only remaining “project” with an id/secret available. This is when the access error for “https: // 127.0.0.1:55661” first appeared. I then attempted the disconnect and reconnect with Chrome—per your message—as the default browser; result the same failure to connect to 127.0.0.1:55661.
So, my question: is the failure to make the connection to 127.0.0.1:55661 going to affect my usage, or my continued usage of OGCS? I ask since the last time this happened; failure to connect to 127.0.0.1:55661;I got one month of OGCS synching before getting the project expired notice and OGCS could not longer sync?
Hope this makes sense out of the question and the steps that I’ve already taken. And as you probably can tell, at this stage OGCS, using the latest id/secret is currently functional; I just want to keep it that way beyond 30-days.
Thanks,
phw198
commented
8 months ago I'm not 100% sure what you mean by the "project expiring" - do you have a screenshot or something of that message? The refresh token does expire every so often, but if your whole API project is expiring, then I'm not sure I've ever seen this before but I doubt very much has anything to do with the authentication fully completing.
Another thing to try, when you get taken back to http://127.0.0.1:55661 can you edit that to http://localhost:55661 and see if that works?
newtonrs
commented
8 months ago Hi Paul,
I think Google must of heard your question, because the issue has returned—see attached image. This is what resulted in my recreating the entire series of steps within Google—it’s referred to by them as a “project”—that provides in the end the OAuth2.0 credentials (ID and secret). You can then find these credentials afterwards and, again, it is listed as a project.
Because of this error when attempting to sync through OGCS and these credentials I removed the “project” (Google’s terminology) and created a new one from scratch at the time of my first mentioning this issue on GitHub.
Anyway, perhaps seeing the error that is reported in OGCS will provide something to help that my explanation has not been able to clearly provide.
If this issue cannot be corrected—and I have no idea why after years of using OGCS this has occurred (I did to the upgrade to 2.10.2.0 Alpha not too long prior to this issue first appearing, but have until now assumed it had nothing to do with the upgrade)—I may have to stop using this amazing product as the error means that I’m not getting an synchronization anyway.
Thanks,
phw198
commented
8 months ago :paperclips: Unfortunately GitHub doesn't support submitting files and screenshots to the ticket when replying by email - please log in to GitHub to upload files.
I suggest you narrow down the issue by reverting to the default OGCS authentication
This would still be my recommendation, to confirm if the issue is with your personal project or failure to talk to the localhost callback URL.
when you get taken back to http://127.0.0.1:55661/ can you edit that to http://localhost:55661/ and see if that works?
Doesn't sound like you've tried this either.
but have until now assumed it had nothing to do with the upgrade
You can always downgrade, but I don't see v2.10.2 introduced any changes regarding OAuth.
newtonrs
commented
8 months ago Hi Paul,
Will do. Will post the image that was attached as well as the information that I’m referring to in Google, and I’ll try to put in the steps that I used to create what is there—that follows the steps outlined in information found with your website for OGCS.
Regarding the use of “localhost”, I did indeed try this instead of the IP address. The result is the same: “unable to connect” in Firefox and “this site cannot be reached” in Chrome.
Thanks,
newtonrs
commented
8 months ago Attached is an image of the process of connecting to my Google/GMail Calendar and the messages along that path. Note that, per your request, I've returned to using the default method of connecting to my calendar.
At this moment, the calendars are again synchronizing. However this worked first for over a year, then for a month and then for few days, using the Google API "project" (as mentioned in a 2020 note for an error synchronizing, and reference elsewhere--issue #1049).
Within the image there is information on the fact that neither the HTTP nor the HTTPS protocols make a difference. Nor does changing from 127.0.0.1 to "localhost" as the target address. Also, note that the web protections of my AV software were disabled during these tests, and that the tests were conducted in both Firefox and Chrome with all extensions disabled. There is one change though, of which I don't know if it is even remotely significant; the port that the URL is trying to connect is different--also noted in the image.
If you can tell me if this final step is important in maintaining the ability of OGCS to function for synchronization, that information would be appreciated. And, if it is important, any ideas/steps on how to resolve the issue would also be appreciated--if you need a "guinea pig" to try various solutions on, I'm willing to be that "guinea pig."
Rick.
Image link below:
phw198
commented
8 months ago I'm afraid you're already the guinea pig as this issue is specific to your computer and its inability to listen to traffic on HTTP localhost. Have you started using a web proxy or its configuration recently changed? As Firefox says, if you have a firewall or proxy blocking access (to localhost), you need to allow that.
Note these things would be a lot quicker to troubleshoot when the OGcalsync.log file is provided.
For the port, I said in an earlier post that the callback port is automatically and randomly generated by the Google OAuth .Net library, so it's absolutely expected to change each time.
Ultimately, as long as you get a Google.Apis.Auth.OAuth2.Responses.TokenResponse-user file after authorising OGCS to manage your calendar, then the process has completely successfully. If this token/your project then expires are some time and you are unable to continue using it, then that sounds like a completely separate issue. I previously asked for a screenshot or evidence of the "project expiring" message you get, but have yet to see this.
newtonrs
commented
8 months ago Hi Paul,
There have been no configuration change—not by me at least. Whether the AV software has made any change in how it processes incoming/outgoing traffic “under the hood,” I cannot say. If a change has been made in the AV software by these companies, it is not notable within anything I have access to within these applications and is not a visible change. I have access to all the available configuration/settings and none have visually changed.
There is no proxy is in use, and never has been. The settings in my AV software are years old—they predate my use of OGCS. My use of OGCS is also years old—though its use post-dates my usage of the AV software by several years. Therefore, it should not be a case of the AV interfering with the application due to any configuration changes on my part.
Regarding Firefox, and Chrome being unable to access “localhost”/”127.0.0.1,” any change to access is not something I implemented. However, it could have been a change in the AV software that has been done internally or a change to the behaviour internal to either of these browsers. No user settings having been altered directly, nor are any visibly changed.
The inability to reach “localhost:
As to the message regarding the “project expiring” and my capturing that error to post, I get that message once only and then synchronization fails going forward. I would create a new project—new name but same configuration—and then generate new credentials based on the new project as the failure results in the set of credentials no longer valid. Not further/subsequent warning message appears; the sync process just fails from that point on.
However, the use of a “project” I created with access to, minimally, Google’s Calendar Api, is something I’ve used for some time before this error occurred. I created this “project” when I was receiving authorization errors when Google started requiring OAuth2.0 authorization from external/non-Google applications accessing their Apis. The information in the issue and its resolution—the creation of a project where the “required to be included” Api is the Google Calendar Api—were found in the reported issues/questions GitHub discussion when I first ran into sync issues (a few updates of OGCS ago); issue number for in my last message. A that time creating the Google “project” with the Google Calendar Api with the generated credentials resolved the issue.
This current error in synchronization may have first appeared after a change to how Google was handling “test-mode” projects—part of a notification a few weeks ago, but prior to the error appearing by a couple of week. I have no way of knowing at whether Google’s change triggered this sync error because of the time between notification and the first time the error appeared. Was it a change at Google regarding projects? Was there a change in OGCS between the current version and the immediately previous version that triggered this error appearing (it did start immediately after the upgrade to 2.10.2.0 Alpha). Or, is it neither and the issue is elsewhere and these other changes are simply coincidental?
At this stage I’ve removed the credentials associated with any project, deleted all projects listed in Google after having received an email from Google yesterday that certain changes were coming for projects. At that stage, and because the projects weren’t changing the failed sync status, I saw no point in updating projects that don’t work for the purpose they were created for. Instead, I disconnected the e-mail accounts within OGCS, then reconnected without using the generated project ID/Secret credentials. So far I’ve been able to sync successfully. Only time will tell if this remains the case—synchronization successfully continues.
Regarding a recorded log file to review, I have set the logging and can send you all the logs I have. However, I have searched the log files for “localhost” and “127.0.0.1” and neither is found in the logs I have for review.
The file Google.Apis.Auth.OAuth2.Responses.TokenResponse-user does exist in the C:\User\
I guess the upshot of this is that I’ll have to wait and see if the process of synchronization continues successfully or at some (undetermined) future date the same issue reappears. At which time I’ll grab the sync error message regarding a failure due to a project with the knowledge that at this time there is no project associated with me of implemented through ID/secret within OGCS.
Not sure, but I suppose because this issue is “in limbo”—perhaps resolved, perhaps not—it should be closed, but necessarily resolved as there is nothing occurring presently and the OGCS logs don’t appear to reveal anything useful.
P.S.: I can take the logs I do have and zip them up and attach them to a posting if that would be of any analytical use to you.
phw198
commented
8 months ago The inability to reach “localhost:
”/”127.0.0.1: ” is new and started with the latest upgrade to 2.10.2.0 Alpha
As already suggested, downgrade and check the problem still exists. My money is on that it will.
I created this “project” when I was receiving authorization errors when Google started requiring OAuth2.0 authorization from external/non-Google applications accessing their Apis.
Not sure what you mean. The default API keys provided by OGCS have always had a project that has been approved by Google - yes there was a change in their requirements a couple of years ago, but I went through the verification process before the deadline, so no one should not have had to set up a personal project. The only reasons for doing so is for those that are very security conscious (not really a valid reason, but each to their own), those that were getting affected by Google's rate limiting (though Google changed their limiting mechanisms and this should not really occur any more), and those that want to sync more often than I allow with the default API keys.
So long story short, you've reverted to the default API keys and everything works as expected (aside from something on your computer blocking incoming localhost traffic) 🙂
You won't get a "project expired" notification using the default project - if you did, that would affect all users, not just you. I don't provide support for people setting up their own project for the exact reason this issue has proved - it is a rather convoluted and error prone exercise! Therefore I think this issue can be closed.
newtonrs
commented
8 months ago Hi Paul,
I’ll be honest, I don’t really want to go through all of the items in the support forums to locate what I read regarding OAuth2.0 and OGCS. I don’t have that kind of time. Yet, I’m fairly certain I read various support items regarding OGCS and OAuth2.0 becoming required by Google for authentication and as such there were changes that were going to be made to adopt OAuth2.0 for OGCS. Perhaps these were old support requests? I don’t really recall.
I just know that when I was having an issue, very much like this one with failed connectivity, I found the information on creating your own OAuth2.0 “project” and then use the credentials from that project—not published but left as a “test” with a test user count of the individual that created the project—and place them into OGCS. As I say, that worked fine for around a year. It was only in the last month, maybe two, that the notice of the project “expiring” that then created synchronization problems (as I described).
I wonder if perhaps my use of the term “project” is just a communication in terminology issue. Maybe what I call what I’m referring to versus what you might when referring to the same thing? For instance, how is OGCS validated by Google? You mention that OGCS’s API Keys have always been approved by Google. Is it not then, a project that has access to the Google Calendar API and has, though hidden from the end-user, a ID/secret pair??
When you say that “there was a change in their requirements a couple of years ago,” I’m assuming that this falls in line with the requirement for OAuth2.0 implementation. I’m also assuming then that OGCS is a “project” that has been set up to have access to the Google Calendar API and that along with that the credentials—ID/secret—were created. These are then coded into OGCS to be automatically, without the end user being aware, provided so that that individual can gain access to their Google Calendar for synchronization. This is what I assume you mean by “approved by Google.”
If that is the case, then it seems that you have created a “project” that has the Google Calendar API associated with it and then gone through the steps to create the ID/secret; so, not too different, other than the project not being in “test” versus “verified” (a.k.a. approved) by Google. If I’m following correctly, and I apologise if I’m wrong, then possibly the most obvious difference is the “test” versus “verified” status.
But, no matter… the fact that it appears all is functioning as it used to after having reverted back to the “default” configuration method—as I say it had stopped working while I was running the immediately previous (which had been working from its release until about two weeks before I made not of it in the forum)—but at the time it was the current release of OGCS. Why that happened, I guess will remain a mystery to us both. Because if I’m following you, there has been no recent change within OGCS that was due to Google requiring OAuth2.0 authentication, or some other change in requirements for OGCS to function with Google/Google Calendar API.
As such, I agree that there is no where further to go at this stage with what happened and the issue can be closed.
P.S.: Regarding rolling back to the immediately previous version, I did try this and, yes, the issue persisted. The strange thing is these recent occurrences are new. I’d never gotten this failure notice previously. Of course, all the browsers—Firefox, Chrome, Brave, Opera and Edge—on my system have seen updates as well, as have my AV applications. All I can say is that with all the AV protections disabled, and no extensions running in either Firefox or Chrome, these connection messages persist. Fortunately, the failure to access the port on the local system doesn’t appear—thus far—to have impeded the synchronization process.
I don’t have a clear picture of what happened to create the issue, not why the browser failure, I’m just glad that at the moment the issue has “disappeared” (hopefully to never return ever again!) and I can again successfully use OGCS. I really do like this product, I was so glad when I found it a few years ago. And whenever it happens that the functioning is “impaired” I look for an answer ASAP so that I can get it up and running again—I guess you’d say I depend on it functioning at all times…fingers crossed that OGCS is back to 100% and that I don’t see any more issues to this vital application.
Thanks,
Rick.
From: Paul Woolcock @.> Sent: Saturday, February 10, 2024 8:41 AM To: phw198/OutlookGoogleCalendarSync @.> Cc: newtonrs @.>; Mention @.> Subject: Re: [phw198/OutlookGoogleCalendarSync] Getting "Connection refused to 127.0.0.1:55661" as the last step after authorizing with Google project for oAuth2.0 access (Issue #1786)
The inability to reach “localhost:”/”127.0.0.1:” is new and started with the latest upgrade to 2.10.2.0 Alpha
As already suggested, downgrade and check the problem still exists. My money is on that it will.
I created this “project” when I was receiving authorization errors when Google started requiring OAuth2.0 authorization from external/non-Google applications accessing their Apis.
Not sure what you mean. The default API keys provided by OGCS have always had a project that has been approved by Google - yes there was a change in their requirements a couple of years ago, but I went through the verification process before the deadline, so no one should not have had to set up a personal project. The only reasons for doing so is for those that are very security conscious (not really a valid reason, but each to their own), those that were getting affected by Google's rate limiting (though Google changed their limiting mechanisms and this should not really occur any more), and those that want to sync more often than I allow with the default API keys.
So long story short, you've reverted to the default API keys and everything works as expected (aside from something on your computer blocking incoming localhost traffic) 🙂
You won't get a "project expired" notification using the default project - if you did, that would affect all users, not just you. I don't provide support for people setting up their own project for the exact reason this issue has proved - it is a rather convoluted and error prone exercise! Therefore I think this issue can be closed.
— Reply to this email directly, view it on GitHub https://github.com/phw198/OutlookGoogleCalendarSync/issues/1786#issuecomment-1937010297 , or unsubscribe https://github.com/notifications/unsubscribe-auth/BCBX77LMPMMPY5BZACYRCMDYS52HZAVCNFSM6AAAAABCOOMEK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXGAYTAMRZG4 . You are receiving this because you were mentioned. https://github.com/notifications/beacon/BCBX77NZP46ETXDJGFCGIMLYS52HZA5CNFSM6AAAAABCOOMEK2WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTTORXHS.gif Message ID: @. @.> >
phw198
commented
7 months ago For instance, how is OGCS validated by Google? You mention that OGCS’s API Keys have always been approved by Google. Is it not then, a project that has access to the Google Calendar API and has, though hidden from the end-user, a ID/secret pair??
Yes, it's a project same as your personal one - when you take it out of test mode, Google will require you to go through a process to have it verified.
All I can assume is that the configuration of your project differs in some manner, which is causing it to expire - but I have no clue what! As I say, I can't really provide support for users configuring their own project for API keys and as long as OGCS works OK with the default installation, then I think I'll have to close this ticket out. Here's hoping you don't encounter any further issue... 🙂
Are you already using OGCS?
Yes, and have been for several years now. Currently running version 2.10.2.0 Alpha.
Describe the question you have
After progressing through the authorization steps to access Google calendar and successfully configuration--at least synchronization is working--a web page opens with an attempt to reach the URL:
"_http://127.0.0.1:55661/authorize/?code=4/0AfJohXl1pJhKYIDy-yPiU6onRJgS3jMu4BtEnpBodfwJWTNQiXx21tlB1Kn1PMKjxViUA&scope=email%20https://www.googleapis.com/auth/calendar%20openid%20https://www.googleapis.com/auth/userinfo.email&authuser=0&prompt=consent"
I've tried accessing just "http://127.0.0.1:55661" and obtain the same "connection refused" error.
To determine if my AV/anti-malware/firewall software was blocking the port/IP address, I tried adding an exception to the firewall configuration, the error persists. I then tried disabling the web protection component. The result is the same error. I have not tried disabling the Heuristics configuration; this is the only step I haven't attempted.
I know that I registered (why I had to uninstall and create a new OAuth2.0 "project" is a different problem that I resolved, unless this is related somehow...) the project, obtained the OAuth2.0 credentials through that Google project and was successfully using OGCS for a month when this afternoon OGCS indicated that the authorization had been "revoked." I then had to go through the process of disconnecting my e-mail account and then re-connecting my account
The questions are: what is the purpose of accessing http://127.0.0.1:55661? Does it complete the actual authorization, and without successfully completing whatever this task in the browser is for this port I'll be having to go through the same issues a month from now, and then a month after that, and...
I don't believe this to be a "bug" but an issue for which more information on the purpose of making this connection is, how to successfully make that connection, and I guess, how important is it that this connection be made to complete the configuration.