Low Level Documentation
Library Fieldpine Internals Replication Gds Security Fpos.dll Startup logic PosGreen Network PosGreen Install Process Multicast Protocol Data Structures Settings Logic Trace


Security Model Product Distribution Gateways Staff Login Stock Levels Shipping Addresses Agency Stores Remote Reports Sales Handlers

PosGreen Engine This engine provides the bulk of the POS processing at checkouts. It can be used directly or via central servers as a remote service.

Contexts & Sessions


Spill Database Debugging

Reference Data

refdata Country refdata SystemString

Gds Security

How an Inbound Connection is Handled

When a new request is generated from a web browser the following outlines how this is handled on a Gds Server.

  • The server receives a TCP connection from the client browser. The source address of the caller is decoded into the source of internet, LAN or localhost using the IANA address allocations.
  • The address source is verified as acceptable for this port using the information in gds.ctl

    As this definition has "type=internet", connections from the internet are permitted. It also has "type=normal", which permits connections from LAN addresses. Localhost connections are always permitted.

    If the source address is not permitted to connect, the server calls closesocket() to immediately terminate the network connection. No HTTP response is sent - this can lead of 502 Bad Gateway type errors if the browser connection went via a CDN, load balancer or proxy

  • Hardcoded network protections are checked using information in gds.ctl
    These protections exist so that network administrators can set rules that cannot be seen or changed using the web management screens.
  • Network level security/velocity stage 1 checks are performed. This feature can be enabled or controlled with "Dynamic Blocking" settings.
    Dynamic blocking is looking for high volume repeated failed access attempts, or access attempts from known script-kiddies that are polling for known access points.
  • The HTTP headers are read and decoded
  • If HTTP headers have any serious anomolies the network connection is dropped and the source IP address added as a potential address for dynamic blocking. While not fully disclosed the range of checks include things such as
    • Excessively large number of headers
    • Excessively long header values
    • Malformed headers that could have side effects
    • Direct checks for known attacks such as struts header attack. We do not use struts.
    Many of these checks may have already been performed if you are using a DDOS service, CDN or intelligent proxy
  • If the connection arrives via a Proxy, CDN or any device that forwards request to the server, then the X-Forwarded-For and equivalent headers are decoded and the original source address extracted. The original source address is also verified according to the checks outlined in the previous step.
  • Security/velocity stage 2 checks are performed now that additional information is available.
  • If security is enabled for the target environment, the firewall rules are processed
    • If any rule performs the action "bypass", all remaining security steps are skipped and request processed
      A bypass rule has a seperate entry are within the web management screens, as it is commonly used, but it is simply a firewall rule no different to any others.
      Bypass rules are intended for common operations that do not need security protection, such as serving public domain images
    • Only those rules that reference network or http header information are processed. Rules that check higher level concepts are deferred until this information is available.
  • If no direct action was taken by the firewall rules (ie it fell through with an explicit accept or block style action) and the server is in "needlogin" configuration the login credentials of the request are checked. This uses the HTTP Authorizaton header and/or X-API-Key header. If these headers do not validly exist a 401 Unauthorized response is returned.