Uploaded image for project: 'Blesta Core'
  1. Blesta Core
  2. CORE-2913

Order: Allow IPs from the x-forwarded-for header

        Details

        • Type: Improvement
        • Status: Closed
        • Priority: Major
        • Resolution: Fixed
        • Affects Version/s: None
        • Fix Version/s: 4.5.0-b1
        • Component/s: None
        • Labels:
          None

          Description

          The Order plugin will log in users and perform other functionality using the client's IP address, but it does so by passing in the server's remote address as the client's IP address, which is not necessarily the case if the server is behind a proxy. Instead, it should follow CORE-2349 and determine the IP address from Blesta's Requestor service

          Update all REMOTE_ADDR references:

          • User log in should not determine the IP address from "REMOTE_ADDR"
          • FraudLabsPro component should not use the "REMOTE_ADDR" IP – it should pull this from the Blesta Requestor instead
          • Creating an order should not set the "REMOTE_ADDR" IP – it should pull this from the Blesta Requestor instead
          • When validating recaptcha, don't use the "REMOTE_ADDR" IP – it should pull this from the Blesta Requestor instead
          • When determining the GeoIP location data, do not base it on the "REMOTE_ADDR" IP – it should pull this from the Blesta Requestor instead
          • Running the anti-fraud check should do so not by using the "REMOTE_ADDR" IP – it should pull this from the Blesta Requestor instead

            Issue Links

            is blocked by

            Improvement - An improvement or enhancement to an existing feature or task. CORE-2349 Add support for the x-forwarded-for header for load balanced environments

            • Major - Major loss of function.
            • Closed

              Activity

              Ascending order - Click to sort in descending order
              tyson Tyson Phillips (Inactive) created issue -
              tyson Tyson Phillips (Inactive) made changes -
              Field Original Value New Value
              Link This issue is blocked by CORE-2349 [ CORE-2349 ]
              tyson Tyson Phillips (Inactive) made changes -
              Story Points 1
              tyson Tyson Phillips (Inactive) made changes -
              Sprint 4.5.0 Sprint 2 [ 67 ]
              tyson Tyson Phillips (Inactive) made changes -
              Rank Ranked higher
              tyson Tyson Phillips (Inactive) made changes -
              Description The Order plugin will perform user log-ins, but it does so by passing in the server's remote address as the client's IP address, which is not necessarily the case if the server is behind a load balancer. Instead, it should follow CORE-2349 and let Blesta determine the IP address rather than providing it on log in. The Order plugin will perform user log-ins, but it does so by passing in the server's remote address as the client's IP address, which is not necessarily the case if the server is behind a load balancer. Instead, it should follow CORE-2349 and let Blesta determine the IP address rather than providing it on log in.

              * Also update the FraudLabsPro component using the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              tyson Tyson Phillips (Inactive) made changes -
              Description The Order plugin will perform user log-ins, but it does so by passing in the server's remote address as the client's IP address, which is not necessarily the case if the server is behind a load balancer. Instead, it should follow CORE-2349 and let Blesta determine the IP address rather than providing it on log in.

              * Also update the FraudLabsPro component using the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead               		The Order plugin will perform user log-ins, but it does so by passing in the server's remote address as the client's IP address, which is not necessarily the case if the server is behind a load balancer. Instead, it should follow CORE-2349 and let Blesta determine the IP address rather than providing it on log in.

              Update all REMOTE_ADDR references:
              * User log in to not determine the IP address from "REMOTE_ADDR"
              * FraudLabsPro component should not use the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              * Creating an order should not set the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              * When validating recaptcha, don't use the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              * When determining the GeoIP location data, do not base it on the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              * Running the anti-fraud check should do so not by using the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              tyson Tyson Phillips (Inactive) made changes -
              Sprint 4.5.0 Sprint 2 [ 67 ]
              tyson Tyson Phillips (Inactive) made changes -
              Rank Ranked higher
              tyson Tyson Phillips (Inactive) made changes -
              Story Points 1 3
              tyson Tyson Phillips (Inactive) made changes -
              Sprint 4.5.0 Sprint 2 [ 67 ]
              tyson Tyson Phillips (Inactive) made changes -
              Rank Ranked lower
              tyson Tyson Phillips (Inactive) made changes -
              Summary Order: Allow log-ins via x-forwarded-for header Order: Allow IP from the x-forwarded-for header
              tyson Tyson Phillips (Inactive) made changes -
              Description The Order plugin will perform user log-ins, but it does so by passing in the server's remote address as the client's IP address, which is not necessarily the case if the server is behind a load balancer. Instead, it should follow CORE-2349 and let Blesta determine the IP address rather than providing it on log in.

              Update all REMOTE_ADDR references:
              * User log in to not determine the IP address from "REMOTE_ADDR"
              * FraudLabsPro component should not use the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              * Creating an order should not set the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              * When validating recaptcha, don't use the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              * When determining the GeoIP location data, do not base it on the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              * Running the anti-fraud check should do so not by using the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead               		The Order plugin will log in users and perform other functionality using the client's IP address, but it does so by passing in the server's remote address as the client's IP address, which is not necessarily the case if the server is behind a proxy. Instead, it should follow CORE-2349 and determine the IP address from Blesta's Requestor service

              Update all REMOTE_ADDR references:
              * User log in should not determine the IP address from "REMOTE_ADDR"
              * FraudLabsPro component should not use the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              * Creating an order should not set the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              * When validating recaptcha, don't use the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              * When determining the GeoIP location data, do not base it on the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              * Running the anti-fraud check should do so not by using the "REMOTE_ADDR" IP -- it should pull this from the Blesta Requestor instead
              tyson Tyson Phillips (Inactive) made changes -
              Summary Order: Allow IP from the x-forwarded-for header Order: Allow IPs from the x-forwarded-for header
              Automated transition triggered when Tyson Phillips (Inactive) created a branch in Stash -
              Status Open [ 1 ] In Progress [ 3 ]
              Automated transition triggered when Tyson Phillips (Inactive) created pull request #72 in Stash -
              Status In Progress [ 3 ] In Review [ 5 ]
              Resolution Fixed [ 1 ]
              tyson Tyson Phillips (Inactive) made changes -
              Remaining Estimate 0 minutes [ 0 ]
              Time Spent 1 hour, 11 minutes [ 4260 ]
              Worklog Id 11675 [ 11675 ]
              tyson Tyson Phillips (Inactive) made changes -
              Sprint 4.5.0 Sprint 2 [ 67 ] 4.5.0 Sprint 2, 4.5.0 Sprint 3 [ 67, 74 ]
              tyson Tyson Phillips (Inactive) made changes -
              Rank Ranked higher
              Automated transition triggered when Tyson Phillips (Inactive) merged pull request #72 in Stash -
              Status In Review [ 5 ] Closed [ 6 ]

                People

                • Assignee:
                  tyson Tyson Phillips (Inactive)
                  Reporter:
                  tyson Tyson Phillips (Inactive)
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Fix Release Date:
                    31/Jan/19

                    Time Tracking

                    Estimated:
                    Original Estimate - Not Specified
                    Not Specified
                    Remaining:
                    Remaining Estimate - 0 minutes
                    0m
                    Logged:
                    Time Spent - 1 hour, 11 minutes
                    1h 11m

                      Agile