OIDC extension generates xwa_filename 967 characters long

Help / Discuss
#1

We are using XWiki v13.10.9 with PostgreSQL and the OpenID extension, v1.34.2. We use it to enable Google SSO.

Generally that works fine, but (only) for one user it fails because at some point a xwa_filename of 967 (!) characters length is generated and tried to be inserted into the xwikiattachment table, while max length is 768 by default. This is the PostgreSQL log entry:

2023-05-12 05:59:22.473 GMT [28637] LOG:  execute <unnamed>: insert into xwikiattachment (XWA_DOC_ID, XWA_FILENAME, XWA_LONGSIZE, XWA_SIZE, XWA_MIMETYPE, XWA_DATE, XWA_AUTHOR, XWA_VERSION, XWA_COMMENT, XDD_CONTENTSTORE, XDD_ARCHIVESTORE, XDD_CHARSET, XWA_ID) values ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13)
2023-05-12 05:59:22.473 GMT [28637] DETAIL:  parameters: $1 = '-592903827727867009', $2 = 'ACB-R5TcLBIiKR7hB09EUOvavgDG1hNwSBvxB1OhzVtEFEOrR0FVeB6q7XOd-wySdcTzogoYeZO-8AIEy9Jk-1Q1bfZpGfeZ59oF6qUOxQLrqFwkyEmVOv4bP5Z4S5OIm3rPMeZ3VqJAoK6IlFAoZaJ5O7t3IOZq_DkfVWGRwZ54BJYDGu-s1HHoOFSEoxpqHr-MS0UFwhGIvzn02PhBrKULLxodSu-Il5j1A1h-5U_9ts8WnSCrBnRlwWcvvsxQFiUc2WF88VIn7neci50OPovNBCENdt22Kk-2ycHqIovBVgkfgE2rbSbnhO3ylnFUrrJWZHbcuT-8yAWYFpsZz8bR9sKF2rE_zmKsRnmqa4yUJbz_oZBQflGe0Pt9ibL22PG-SFUIvdooXUYtZ1wdVOJcaNo2SwNru16FYtl5TZWRCSIyyC9UKpFz_PzmGS9Hp5rlzPQjHaISbczpnHUA-SQaO9_IWjeDlILbHBhQ3jSiNjFGPrpK6UCqGK0Z9hBHy-LoOjYe499q6AF-baOZzfIo_UBTgyyM0Znq2HpYVx44vPZGyLWEq0haVV88Wo13MuWuKk4rgYntTbEw7apCa_UvvQfwJ7msvVHUa8KXEYOT7mbg2uzeDheHrLCctQztjhwDXT6p7JACR2Kk9SS9rs7S678dkLJVwrJsaCmn6NNDpBNOiucJQI74-c9kPEIBHLVfrTTlDqtYRD7gQYDRtPp0otmZoop9-NpjQjZ7AkUHYxI3FEtt4c7s8i4YceCXcJPqy7Cy2bF7JS0xDAdZ1-VUyIqyxeaHCQ1pHd3hVoxG4-Ut4eVg86O9aTYpMHOA59fpuB4pX0Gvr1qRAy7Xpr2OUxzs6K9bHyJr8a3_1d09PF-YnEi79aalYEVvkXCHvgg0Npww4antO-k_zSISnsazWxuZqSaliZXzdGMGLp-nagsk8b43XbJ6UQhqdDpF=s96-c', $3 = '6953', $4 = '6953', $5 = NULL, $6 = '2023-05-12 05:59:22.427', $7 = 'XWiki.XWikiGuest', $8 = '1.1', $9 = '', $10 = 'file', $11 = 'file', $12 = NULL, $13 = '992899880'

We tried to workaround this by increasing the column length from 768 to 4000 (that seemed to be a low-risk measure as the column has no FK constraint and no index). After doing this, the xwikiattachment insert went through but then it failed with the same error in xwikistrings table. We could increase this as well but I’m not very happy with messing around in the database in several tables (no idea which other insert might fail still). Also for obvious potential problems when upgrading later.

As this obviously seems to be for the user avatar file, we also tried to update it in the profile (with a short filename ofc), with no luck. In that case a different but also 967 characters long filename was generated.

Any recommendations very appreciated.

#2

Note that the OIDC authenticator does not generate any file name, it just takes the file name given by the OIDC provider (in the userinfo picture URI property). I definitely did not expect providers sending such long file names…

Maybe that’s something you can control on the provider side, but I would not bet on it with Google.

Otherwise, I guess we should try to add some bulletproofing for this, but not sure what’s the best to avoid collision. The less bad thing I can think of is to hash the received file name if it’s longer than the maximum attachment name size. Another possibility would be to use some arbitrary file name like oidc.<the file extension found in the picture URI>.

Would be great if you could create an issue on Loading... describing the situation.

#3

Sure. OIDC-142

We checked it - the 967 characters are really provided by Google, sorry for blaming the extension. (I’d change the thread title here but that seems not to be possible any more.)

#4

It’s OK, in the end this name is chosen by the authenticator, and we’ll have to bulletproof that as I’m not sure we can avoid it (it’s not like it was the only thing in that authenticator to deal with strange providers).