Can’t authenticate on local/dev/staging installation

  • Resolved Jer Clarke

    (@jerclarke)


    2 years ago

    Hi, first thank you so much for making this plugin! I have looked at all the big ones and they are so bloated and corrupt with marketing, I’m really glad to find your plugin which is simple yet powerful.

    I got it working on a Dreamhost-hosted site (basic hosting) and it’s great!

    Now I’m trying to use it for our non-profits more “enterprise” sites, where the first step is testing it on the local copy of the sites on my laptop.

    For some reason the authentication just keeps failing. Is this normal/expected? Does the site have to be visible online like with the Google Site Kit plugin?

    When I go to admin.php?page=aiwp_settings I always see this message:

    Something went wrong, check [Errors & Debug] or [authorize] the plugin.

    When I click “Authorize Plugin” it seems to work. I get taken to Google, accept, then come back, but just see the same buttons as before along with the “Something went wrong” message.

    Thank you so much for any help you can provide! I would love to choose this plugin and work on it with you in the future! I see you have a GitHub and would love to submit some PR if I can get it working!

    Here’s my debug stuff:

    PHP Error log: I checked the PHP Error log and there was nothing there.

    Error details: The count goes up for each time I click Authorize and go through the process with google: 

    Error Details
Count: 4
Last Error: 
GAPI Error:
    Sampled Data
None

    Plugin configuration is basically default:

    Plugin Configuration
Array
(
    [client_id] => 
    [client_secret] => 
    [access_front] => Array
        (
            [0] => administrator
        )

    [access_back] => Array
        (
            [0] => administrator
        )

    [tableid_jail] => 
    [webstream_jail] => 
    [theme_color] => #1e73be
    [switch_profile] => 0
    [tracking_type] => globalsitetag
    [reporting_type] => 0
    [ga_anonymize_ip] => 0
    [user_api] => 0
    [ga_event_tracking] => 0
    [ga_event_downloads] => zip|mp3*|mpe*g|pdf|docx*|pptx*|xlsx*|rar*
    [track_exclude] => Array
        (
        )

    [ga_target_geomap] => 
    [ga_realtime_pages] => 10
    [token] => 
    [ga_profiles_list] => Array
        (
        )

    [ga4_webstreams_list] => Array
        (
        )

    [ga_enhanced_links] => 0
    [ga_remarketing] => 0
    [network_mode] => 0
    [ga_speed_samplerate] => 1
    [ga_user_samplerate] => 100
    [ga_event_bouncerate] => 0
    [ga_crossdomain_tracking] => 0
    [ga_crossdomain_list] => 
    [ga_author_dimindex] => 0
    [ga_category_dimindex] => 0
    [ga_tag_dimindex] => 0
    [ga_user_dimindex] => 0
    [ga_pubyear_dimindex] => 0
    [ga_pubyearmonth_dimindex] => 0
    [ga_aff_tracking] => 0
    [ga_event_affiliates] => /out/
    [backend_item_reports] => 1
    [backend_realtime_report] => 0
    [frontend_item_reports] => 0
    [dashboard_widget] => 1
    [api_backoff] => 0
    [ga_cookiedomain] => 
    [ga_cookiename] => 
    [ga_cookieexpires] => 
    [pagetitle_404] => Page Not Found
    [maps_api_key] => 
    [tm_author_var] => 0
    [tm_category_var] => 0
    [tm_tag_var] => 0
    [tm_user_var] => 0
    [tm_pubyear_var] => 0
    [tm_pubyearmonth_var] => 0
    [web_containerid] => 
    [amp_containerid] => 
    [amp_tracking_tagmanager] => 0
    [amp_tracking_analytics] => 0
    [amp_tracking_clientidapi] => 0
    [trackingcode_infooter] => 0
    [trackingevents_infooter] => 0
    [ecommerce_mode] => disabled
    [ga_formsubmit_tracking] => 0
    [optimize_tracking] => 0
    [optimize_containerid] => 
    [optimize_pagehiding] => 0
    [superadmin_tracking] => 0
    [ga_pagescrolldepth_tracking] => 0
    [tm_pagescrolldepth_tracking] => 0
    [ga_event_precision] => 0
    [ga_force_ssl] => 0
    [ga_optout] => 0
    [ga_dnt_optout] => 0
    [tm_optout] => 0
    [tm_dnt_optout] => 0
    [ga_enhanced_excludesa] => 0
    [ga_hash_tracking] => 0
    [aiwp_hidden] => Y
    [sites_list_locked] => 0
    [wp_version] => 6.0.2
    [aiwp_version] => 5.7.7
)
    System Information
Server Info: nginx/1.19.2
PHP Version: 7.3.27
cURL Info: 7.68.0 OpenSSL/1.0.2u
Gzip: Yes

    More info: macOS 12.6 running MAMP Pro 6.4.2.

    • This topic was modified 2 years ago by Jer Clarke.
Viewing 8 replies - 1 through 8 (of 8 total)
  • Plugin Author Alin Marcu

    (@deconf)

    Hi,

    As long as you have an internet connection it works, no need to be a live site.

    Make sure you are authorizing with a Google account containing at least one Google Analytics account with a property and start by:

    1. Using the same browser in incognito/private mode with all extensions disabled

    2. Trying with a different browser

    3. Authorizing with all other plugins disabled, just in case there is some sort of plugin conflict

    4. Checking the Errors and Debug screen right after the failed authorization

    5. Making sure your local server has the date and time properly configured.

    6. After authorization what buttons do you have available on main screen and are there any properties listed?

    Thread Starter Jer Clarke

    (@jerclarke)

    Thank you so much for the quick reply!!!

    1/2/3: I just tried everything you said and still the same problem: Switched to a private tab in Safari where I have no extensions, switched to a totally vanilla site with no other plugins installed.

    4: The Errors and Debug screen always has the same thing, just the number of times I tried to auth as the count of errors and nothing else.

    5: I don’t know how to really approach this. Can you explain why this would break it? My WP is configured to use UTC+0 time to match the server, and that’s what I see in my PHP error log for example. My computer is in Mexico City time (UTC -5 currently)

    Here’s how it looks both before and after I go through the whole process with Google on my clean site:

    View post on imgur.com

    So it seems like the problem starts before the auth process.

    I also just tried switching to PHP 8.0.3 (newest available in MAMP Pro) and the problem is still the same.

    Really strange! I’ll have to go in and start debugging. Any tips you have for me on where to look would be appreciated.

    Plugin Author Alin Marcu

    (@deconf)

    When I click “Authorize Plugin” it seems to work. I get taken to Google, accept, then come back, but just see the same buttons as before along with the “Something went wrong” message.

    Since the authorization flow seems to work properly from your first post, I wonder if there isn’t a firewall rule or something that is blocking access to api.deconf.com.

    While should throw a descriptive error, it seems that the Google endpoint does provide the access code which is never exchanged with an access token with Deconf’s endpoint (api.deconf.com).

    Thread Starter Jer Clarke

    (@jerclarke)

    Thank you! I looked for that domain and found where it’s used for auth, I managed to get my debugger to this point:

    View post on imgur.com

    Any idea why it would be marked as SSL expired? I looked at the api link in my browser and the SSL was fine.

    Still investigating but figured I’d share. Thanks for the help!

    Plugin Author Alin Marcu

    (@deconf)

    Since you’ve already check the date and time on your server I would recommend trying to update the default server CA bundle, it must be related to that.

    Thread Starter Jer Clarke

    (@jerclarke)

    Fixing the SSL problem with MAMP

    FIGURED IT OUT!!! Thank you for your help.

    I traced it down through the Google apiclient vendor library, down to Guzzle, where I could make it work by disabling all verification:

    https://cdn.discordapp.com/attachments/838146587372552232/1027966579180326933/Screen_Shot_2022-10-07_at_10.31.29.png

    But this wasn’t a solution at all, because even you shouldn’t modify that file (I was thinking of asking you to add a filter for me to use on my dev machine, but that would be terrible considering it’s a Google library you don’t control).

    So then I kept digging and finally found this Stack Overflow answer which is specific to MAMP Pro. It seems that MAMP Pro has a long-standing bug related to their cacert.pem file.

    By replacing the cacert.pem file from MAMP Pro with the one from curl, I got the plugin working with verify enabled in Guzzle!

    SO: If you hear of others with this problem on macOS/MAMP Pro, please point them to that SO post, or this thread, as it’s a relatively easy fix.

    I will investigate with MAMP Pro themselves as to why this fix is needed, since of course it will be annoying to re-do this every time MAMP updates!

    _____

    Surfacing the SSL error in AIWP

    In terms of AIWP, the only loose-end is the fact that the error didn’t surface at all. A normal user would never have been able to figure out it was an SSL error since there was nothing in the logs and nothing on the screen, but it seems like the exception thrown by Guzzle was available to AIWP, so it could have been shown.

    Would you like me to work on trying to surface that error? Do you want to take a stab at it?

    I don’t know how you would normally surface an error to the UI of the settings page, so if you want me to look at it, any tips on how to do that would be helpful.

    It seems like you already log the error, as seen in the first screenshot I sent of AIWP_GAPI_Controller->authenticate(), so maybe the point is to just make sure that errors from AIWP_GAPI_Controller->set_error() get shown?

    Thank you so much for your help in this thread, I am very impressed with your attention to this plugin!

    ___

    P.S. If you need a way to replicate this problem to make sure the error gets surfaced, this one-line edit to the Google apiclient will have the same effect as the bug in MAMP:

    https://cdn.discordapp.com/attachments/838146587372552232/1027976515805257829/Screen_Shot_2022-10-07_at_11.11.24.png

    • This reply was modified 2 years ago by Jer Clarke.
    Plugin Author Alin Marcu

    (@deconf)

    Hi,

    Nice work.

    In terms of AIWP, the only loose-end is the fact that the error didn’t surface at all. A normal user would never have been able to figure out it was an SSL error since there was nothing in the logs and nothing on the screen, but it seems like the exception thrown by Guzzle was available to AIWP, so it could have been shown.

    I already tried to fix it. From my tests, there was an uncovered condition which caused the error not to store. To be more specific, if the error was an object but not with the expected properties it was just ignored and not stored as it should. See this pull request which should fix the issue:

    https://github.com/deconf/Analytics-Insights/pull/6/commits/20d8e22176e161449cb4f492cafb0fbe07eda8a1

    Thread Starter Jer Clarke

    (@jerclarke)

    Magnificent, amazing you already have a patch! I can see the error!

    The only thing is the error I see is “invalid json token”: https://cdn.discordapp.com/attachments/838146587372552232/1027988342660411452/Screen_Shot_2022-10-07_at_11.58.20.png

    It seems that when the page reloads, the new error caused by not having a token replaces any older one about SSL. Does that sound right?

    I actually noticed this token as the superficial problem when I was first debugging, but quickly found it was just a symptom of the auth failing.

    This kind of points to a potential larger change to the plugin that is probably out-of-scope. Ideally any exceptions encountered during auth would be shown immediately when the page reloads, rather than in that error screen, and if there’s multiple errors they’d all be shown. That would be a huge change though, so I understand if you don’t want to touch it!

    Another alternative would be to just give this token error special handling and make sure it doesn’t take up the “last error” slot, since it probably won’t be helpful very often.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Can’t authenticate on local/dev/staging installation’ is closed to new replies.