How to Refactor Java Login Security: Clean IP and Time Restrictions

Business Overview

The existing system already has a login feature; the goal is to add security constraints that limit login by IP address (internal or external) and by allowed login time.

Original Code Issues

The original login code suffers from several problems:

String matching is used for boolean checks; a direct boolean should be used.

Time handling is hard‑coded; it should be extracted to a utility class.

String splitting (comma‑separated values) is duplicated across the codebase; a reusable utility method is needed.

Three business checks (allowed time, internal IP, external IP) are tangled together, making the logic hard to read and modify.

SecureLogEvent objects are created without passing key business data.

Very few comments make critical code difficult to understand.

Method names are vague and do not clearly describe their purpose.

Magic numbers/strings are scattered throughout; they should be replaced with named constants.

Refactoring Process

The refactor was performed in several systematic steps:

Read the original code and locate duplicated logic.

Extract time‑handling logic into a private helper method.

Write a small main test for the new time method; once verified, replace the original time handling.

Identify common string‑splitting code, create a private utility method, test it, and replace all occurrences.

Separate the "allowed login time" check from the nested loops, turning it into an independent condition.

Split internal‑IP and external‑IP checks into their own loops, removing the double‑loop structure.

After clarifying the business rules, the code hierarchy becomes straightforward.

Enhance logging by adding valuable business data, add comments, and replace magic values with constants.

Change the call site to use a boolean‑returning method instead of the previous private call.

Move the rule‑checking logic out of CreditController into a dedicated utility class to reduce controller size and improve responsibility separation.

Refactored Code Highlights

Key changes in the refactored implementation include:

Definition of constants at the top of the class for all magic values.

A single public method that first checks the allowed time via forbitVisitTimeRange.

Separate isInside and isOutside methods that each call a private checkRange, eliminating the previous double‑loop.

A private recordLog method that accepts a concatenated business‑data string, making logs more informative.

Key Takeaways

Avoid duplicated code; extract reusable methods whenever repetition is found.

Leverage existing framework or third‑party utility classes instead of reinventing common functionality.

When multiple loops are present, evaluate whether each business rule can be isolated into its own method.

Provide clear comments for critical sections to greatly improve readability.

Replace magic numbers/strings with well‑named constants.

Log meaningful business data to aid future debugging and incident analysis.