#GoogleHandling

[venkat3681]

Explore the July 2023 Google ranking algorithm updates and their impact on search results. Discover the ongoing volatility, webmaster frustrations, and uncertain expectations in the SEO community. Learn about the latest tracking tool insights and the prevalent attitudes towards Google's handling of the situation.

GoogleAlgorithmUpdates #July2023SEOChanges #SearchResultImpact #WebmasterFrustrations #SEOCommunityInsights #VolatilityInSearchResults #TrackingToolAnalysis #GoogleHandling #SEOExpectations

[xarql-blog]

Authorization/Authentication

My use of four letter path names on the root path has prooved itself to be a defect as it has lead to my indecision between calling this new security feature authorization or authentication. An HTTP 401 error means "Unauthorized" but the site represents that as "Unauthenticated". xarql.com shows it that way becuase the users are always anonymous, and as such their posts won't be connected to an author. The end user probably won't notice the difference, but it caused me a headache while naming things.

Regardless, the goal is to ensure the client is a real user while being less invasive than multiple recaptchas. Users go to xarql.com/auth and either sign in with Google or complete a recaptcha to authenticate their session. This only has to be done once as long as they hold on to the their session cookie and it hasn't been an hour since the authentication.

The point is to stop abuse. This massively reduces the risk of a script hitting an endpoint successfully, as it will not have an authenticated session. If a script hits /polr/post?title=spam&content=spam&answers=0 it will simply return a 401 error, instead of producing the intended spam on /polr.

Behind the scenes there are several classes at work. MainAuthPage puts users on /auth and displays whether or not they're authenticated. GoogleHandler interprets requests from /auth/google and creates an AuthSession using the VerifyGoogle class. RecaptchaHandler interprets requests from /auth/recaptcha and creates an AuthSession using VerifyRecaptcha. These AuthSessions are added to AuthTable upon creation. AuthTable then provides access to them to other servlets.

AuthSession

When an AuthSession is created it is done either by "google" or "recaptcha". These have respective classes that do processing, and if they succeed the AuthSession will change its verified status to true. tomcatSession is used to set up the match between the client's cookie and the AuthSession. The AuthSession always generates a completely random color for itself and sets creationTime to the current Timestamp. .expired() returns true if the creationTime was more than 60 minutes ago. If the "google" option is used, the AuthSession will also have its googleId available.

AuthTable

This has a static TrackedHashMap that stores matches between a String, that represents a tomcatSession, and an AuthSession. Servlets call AuthTable.contains(String tomcatSession) to determine if the client has been authenticated. Adding an AuthSession to the AuthTable will replace the last AuthSession which has the same tomcatSession if it exists. On every 8th addition, AuthTable calls trim(). That removes all AuthSessions that have expired in order to reduce the risk of collisions and memory issues.

TrackedHashMap

This is a combination of ArrayList and HashMap. This allows for both grabbing an unknown Object based on a known Key and grabbing an unknown Key based on a known Index. The combination allows for functions like .randomKey(). It would be hard to do things where the keys inside of the HashMap aren't indexed. Example : For AuthTable an ArrayList wouldn't be suitable becuase it doesn't have an optimized way to grab the AuthSession based on its tomcatSession and a HashMap wouldn't be suitable because we need to be able to check if any of the AuthSessions have expired by iterating over them. Overall, TrackedHashMap provides certain utilities with good performance that neither a map nor list could.