[mitreid-connect] Upgrade DB schema from 1.1.x to 1.2.x

[Luiz Omori]

I know about GET/POST. Just trying to explain why we started with POSTMAN. The last step requires a POST, not sure how to do it straight from Chrome/Firefox without a plugin.

You are right, it’s the "authorization holder”. The retrieved JSON was too large (80+ MB) and a bit hard to follow things.

Yes, we are running the cleaner, however the version in production is missing the JTI for ID tokens, which causes an exception in the cleanup task when duplicates are found, which in turn prevents part of the cleanup task to execute :(

Regards,
Luiz

From: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Date: Thursday, December 10, 2015 at 1:57 PM
To: Luiz Omori <luiz.omori at dm.duke.edu<mailto:luiz.omori at dm.duke.edu>>
Cc: "mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>" <mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>>
Subject: Re: [mitreid-connect] Upgrade DB schema from 1.1.x to 1.2.x

The “GET” extracts the data, the “POST” uploads the data.

What that means is that you’ve got a lot of “user approved sites” on that server. You should have only one per user/site pair. However, the object you have listed below isn’t a “grant” it’s an “authorization holder” which should be getting cleaned up by the server’s timed scripts. Are you running those?

They should expire as the tokens and other objects that they help run expire.

 — Justin

On Dec 10, 2015, at 1:34 PM, Luiz Omori <luiz.omori at duke.edu<mailto:luiz.omori at duke.edu>> wrote:

Yes, we were not planning to use the old schema. It occurred by mistake when we were testing the newer version.

I was testing the upgrade procedure by extracting the data from one of our production servers and send it to a test server. Since a POST is need, was using POSTMAN but it kept crashing. Then tried a simple GET from the browser after logging in and got an extremely large JSON. It has 67038+ entries under “grants”.  See example below. Any idea of what could be wrong? We will debug it otherwise. Our concern is that this info is being stored there and if unbounded the server is going to blow up at some point.

     {
        "id": 67038,
        "ownerId": null,
        "authentication": {
          "clientAuthorization": {
            "requestParameters": {
              "grant_type": "password",
              "client_secret": <removed>,
              "client_id": <removed>,
              "username": <removed>
            },
            "clientId": <removed>,
            "scope": [
              "openid",
              "profile"
            ],
            "resourceIds": [],
            "authorities": [],
            "approved": true,
            "redirectUri": null,
            "responseTypes": [],
            "extensions": {},
            "extensionStrings": {}
          },
          "userAuthentication": "rO0ABXNyAE9vcmcuc3ByaW5nZnJhbWV3b3JrLnNlY3VyaXR5LmF1dGhlbnRpY2F0aW9uLlVzZXJuYW1lUGFzc3dvcmRBdXRoZW50aWNhdGlvblRva2VuAAAAAAAAATYCAAJMAAtjcmVkZW50aWFsc3QAEkxqYXZhL2xhbmcvT2JqZWN0O0wACXByaW5jaXBhbHEAfgABeHIAR29yZy5zcHJpbmdmcmFtZXdvcmsuc2VjdXJpdHkuYXV0aGVudGljYXRpb24uQWJzdHJhY3RBdXRoZW50aWNhdGlvblRva2Vu06oofm5HZA4CAANaAA1hdXRoZW50aWNhdGVkTAALYXV0aG9yaXRpZXN0ABZMamF2YS91dGlsL0NvbGxlY3Rpb247TAAHZGV0YWlsc3EAfgABeHABc3IAJmphdmEudXRpbC5Db2xsZWN0aW9ucyRVbm1vZGlmaWFibGVMaXN0_A8lMbXsjhACAAFMAARsaXN0dAAQTGphdmEvdXRpbC9MaXN0O3hyACxqYXZhLnV0aWwuQ29sbGVjdGlvbnMkVW5tb2RpZmlhYmxlQ29sbGVjdGlvbhlCAIDLXvceAgABTAABY3EAfgADeHBzcgATamF2YS51dGlsLkFycmF5TGlzdHiB0h2Zx2GdAwABSQAEc2l6ZXhwAAAAAncEAAAAAnNyAEJvcmcuc3ByaW5nZnJhbWV3b3JrLnNlY3VyaXR5LmNvcmUuYXV0aG9yaXR5LlNpbXBsZUdyYW50ZWRBdXRob3JpdHkAAAAAAAABNgIAAUwABHJvbGV0ABJMamF2YS9sYW5nL1N0cmluZzt4cHQAClJPTEVfQURNSU5zcQB-AAt0AAlST0xFX1VTRVJ4cQB-AApwcHNyAEFvcmcuc3ByaW5nZnJhbWV3b3JrLnNlY3VyaXR5LmxkYXAudXNlcmRldGFpbHMuTGRhcFVzZXJEZXRhaWxzSW1wbAAAAAAAAAFAAgAKWgARYWNjb3VudE5vbkV4cGlyZWRaABBhY2NvdW50Tm9uTG9ja2VkWgAVY3JlZGVudGlhbHNOb25FeHBpcmVkWgAHZW5hYmxlZEkAFGdyYWNlTG9naW5zUmVtYWluaW5nSQAUdGltZUJlZm9yZUV4cGlyYXRpb25MAAthdXRob3JpdGllc3EAfgADTAACZG5xAH4ADEwACHBhc3N3b3JkcQB-AAxMAAh1c2VybmFtZXEAfgAMeHABAQEBf____3____9zcQB-AAVzcQB-AAkAAAACdwQAAAACcQB-AA1xAH4AD3hxAH4AFHQATmNuPUNBVFNfZGFzaHNydixvdT1TZXJ2aWNlQWNjb3VudHMsb3U9RW50ZXJwcmlzZUFjY291bnRzLGRjPWRoZSxkYz1kdWtlLGRjPWVkdXB0AAxDQVRTX2Rhc2hzcnY=",
          "savedUserAuthentication": {
            "name": <removed>,
            "sourceClass": "org.springframework.security.authentication.UsernamePasswordAuthenticationToken",
            "authenticated": true,
            "authorities": [
              "ROLE_ADMIN",
              "ROLE_USER"
            ]
          }
        }
      },

Regards,
Luiz

From: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Date: Thursday, December 10, 2015 at 10:48 AM
To: Luiz Omori <luiz.omori at dm.duke.edu<mailto:luiz.omori at dm.duke.edu>>
Cc: "mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>" <mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>>
Subject: Re: [mitreid-connect] Upgrade DB schema from 1.1.x to 1.2.x

You cannot run a new server against the old schema, this is completely unsupported.

You need to export the data from the old server, drop the schemas, load the new schema from the appropriate DB file, and re-import the data. Upgrade instructions are here:

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/wiki/Upgrading-to-1.2

UserInfo is not exported or imported as most instances of MITREid Connect handle user account management externally.

 — Justin

On Dec 10, 2015, at 9:46 AM, Luiz Omori <luiz.omori at duke.edu<mailto:luiz.omori at duke.edu>> wrote:

Hi,

Are there any scripts to upgrade the DB schema from 1.1.x to 1.2.x? By chance we run into some issues, for example with the new column client_details::clear_access_tokens_on_refresh, when trying to run a newer server against an old schema.

Regards,
Luiz
_______________________________________________
mitreid-connect mailing list
mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>
http://mailman.mit.edu/mailman/listinfo/mitreid-connect


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20151210/650d9708/attachment-0001.html