spring kerberos missing negotiated request

I have a spring security based kerberos authentication which has been working fine, however, suddenly it started missing the negotiated request (the 2nd request from client after spring initiated the NEGOTIATE).

1st state:

somehow, instead of sending two requests from client, spring only received the first request, followed by a call to /favicon, which instead should be same endpoint if it’s working.

I have then added /favicon to the permitAll() list, which then resulted in 2nd state.

2nd state:

only single request reached to spring MVC
Lesson learnt here, it could never log too much during debuging/troubleshooting

It took me really a great mount of time to figure this out, but in short, it’s due to the HTTP header from client after KDC/TGT’s encrypted message suddenly become larger (likely KDC/TGT has sent more data) than tomact default threshold.

The changes:

The working result:

docker non-root with NFS mount

there are two steps in switch docker to non root and mount with NFS. however, there are several knowns issues with the switch as well

  1. switch to non root
//in dockerfile

//add the group and user
RUN groupadd -g $GID <groupname> && useradd -lms /bin/bash -g $GID -u $UID <username>

//switch to non root
USER <username>

the group id and user is needed in order to mount the NFS or any existing directory for the existing user (the non root user). otherwise, it’s not needed if mount is not needed.

there is an issue with large group id and user id,



the solution is to disable the logging, which otherwise would explode the lastlog and faillog in docker, which took more than 200GB in our case for a super large user id (9 digit).

2. then to mount the NFS, if its existing directory, the file/folder permissions would copied over to the container (now with same user/group id)



pass in null parameter from jdbctemplate

i have a query where some of the parameter is optional, something like

String PERMS = """
  select .....
  where ...
  and (:app is null or a.app=:app)

this query and corresponding DAO method works fine when the parameter is not null, however would fail for both jdbctemplate or namedJdbcTemplate.

Turned out the trick is two folded:

  1. from the sql side, tell the dbms and its driver what’s the type of the optional parameter
String PERMS = """
  select .....
  where ...
  and (:app::text is null or a.app=:app)

2. with namedjdbcTemplate, pass in the type (0) to the jdbc driver

MapSqlParamterSource params = ..
params.addValue("app", null, Types.NULL)

Kerberos on IIS

follow up to https://lwpro2.wordpress.com/2022/07/23/kerberos-authentication/, it turns out IIS (windows server) has authentication (either Kerberos or NLTM) baked in.


and this is config for our server which worked out well with NLTM and single server (single HOST SPN)

then from server (python/java), retrieve the token of user and host:

netflix dgs graphql with nginx

when dgs is running behind a reverse proxy, the graphiql is not working:

Expected behavior

When dgs is accessed directly, the graphiql is working.

When dgs is accessed from reverse proxy, the graphiql should work as well.

Actual behavior

When dgs is accessed from reverse proxy, the graphiql stopped working.

Steps to reproduce

  1. set up nginx as a reverse proxy, point /data to the backend dgs service (assume it’s dataprovider)
  2. access graphiql from http://<nginx_server>/data/graphiql

Note: A test case would be highly appreciated, but we understand that’s not always possible

Some RCA

The issue is due to in graphiql, its trying to fetch the graphql path as absolute path:

this would assume the graphql is at the root, which won’t be true with an existence of reverse proxy.

Possible Solution

The solution is to change that path to a relative path as ./graphql.



The fix is to point dgs graphiql at the relative path instead of root:

PR: https://github.com/Netflix/dgs-framework/pull/1204

With MR: #1204, and bump dgs version to 5.2.1, it’s now working both w/ and w/o reverse proxy.



cname vs a record


A Canonical Name or CNAME record is a type of DNS record that maps an alias name to a true or canonical domain name. CNAME records are typically used to map a subdomain such as www or mail to the domain hosting that subdomain’s content.


vs a record

An A record maps a domain name to the IP address (Version 4) of the computer hosting the domain. An A record uses a domain name to find the IP address of a computer connected to the internet


the difference, in a nutshell, being, cname normally is an alias mapping to a single server. while A record should map to a list of servers, which could be load balanced.