I have a use case for adding negative lookbehind to my oathkeeper rules. I came across https://github.com/ory/oathkeeper/issues/441 and have joined that conversation; offering my 2c on the topic. Since ory/oathkeeper uses ory/ladon (for parsing the regexp from the config) and dlclark/regexp2 (as the underlying regexp engine), and dlclark/regexp2 supports lookbehinds (positive and negative) as well as possessive matches, I made the following changes: • Updated ory/ladon's

regex.go

to support multi-byte delimiters by slightly refactoring the

delimiterIndices

to process

[]rune

(

string

cast to

[]rune

) and

rune

(

byte

cast to

rune

) for the

pattern

,

delimiterStart

, and

delimiterEnd

parameters respectively. • Updated ory/ladon's

regex.go

CompileRegex

to send

delimiterIndicies

parameters cast properly and gently refactored the internal for loop to support the update from

string

to

[]rune

. • Why? Processing the

string

as a

[]rune

eliminates the importance of the delimiter byte length. Each "character" of the string is processed as a distinct "character". Since these characters can be multi-byte, using

[]rune

eliminates the need to care. This means that a pattern can look like this: ◦

urn:foo:«(?<type>\w+):(?<id>(?<!hax:)\w+)»

or

urn:foo:<<(?<type>\w+):(?<id>(?<!hax:)\w+)>>

and inputs

urn:foo:person:user1

or

urn:foo:user:user2

would match but

urn:foo:haxor:user3

would not match. • But... Why? My use-case requires negative lookbehind to make my oathkeeper rules not make me want to cry. Since oathkeeper uses dlclark/regexp2, lookbehind (and friends) are already supported out-of-the-box. The issue is that within oathkeeper (read: ladon) there is a bug that occurs when it attempts to parse a rule with

(?<

or

(?>

included in the pattern; as would be the case for positive lookbehind, negative lookbehind, and possessive matches. My modification fixes this.