Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

OAuth Domain mismatch

Hi,
I've been trying to simulate virtual hosts on a tomcat deployment of RTC301 so that I have the option of moving to WAS and splitting apps across servers at a later date. To this end I created two DNS aliases for the same nost, one for jts and one for ccm. During setup, I deleted the auto discovery of CCM and added my own using the second DNS alias for ccm - all seemed ok but I get this error in the diagnotics and I can't figure out how to fix it.
The error says
Application : the discovery resource at https://rtcjts.company.com:9443/ccm/rootservices for /ccm has different OAuth domains than the entry does.
OAuth domains from the discovery resource:
Application: there is no OAuth domain in the discovery resource at https://rtcjts.company.com:9443/ccm/rootservices for /ccm that is a prefix of the discovery resource URI.
This could be caused by changing the public URI setting in the applicatin or friend.
Oauth domains from the discovery resource [https://rtcccm.company.com:9443/ccm

The first time I ran setup, I made a mistake and registered the ccm app wit hthe auto discovered URI. I removed this and then redid the setup adding manually with the URI I wanted for ccm.

i found a reference to the incorrct uri (https://rtcjts.company.com:9443/ccm in the friends.friend table - fixing this did'nt fix it - (btw I made a vm image of the real machien to try this on)

Any suggestions on where to look to fix this greatfully received - we have real data in this instance as it wasn't noticed immediately - not the end of the world but would prefer to recover this instance if possible

Thnaks in advance

0 votes



2 answers

Permanent link
Hi Alan,

For a registered application, the diagnostic checks that the OAuth domains reported in both the /scr and /rootservices resources are prefixes of the URLs for those resources. It sounds like you originally registered the CCM application with the URL "https://rtcjts.company.com:9443/ccm/scr", then un-registered it and re-registered it using "rtcccm.company.com" as the hostname? If so, that should have fixed it up, unless the public URI of the CCM application still had "rtcjts.company.com" for the hostname.

In any case, it seems that the registered application entry stored in the JTS database has "rtcccm.company.com" stored in the SCR URL, but "rtcjts.company.com" stored in the rootservices URL. You should be able to fix that by making sure the CCM public URI uses "rtcccm.company.com", then un-registering and re-registering it again.

1 vote


Permanent link
Hi John,
@jrvasta
Are there any side effect to doing that - i did look at going downthat route but I seem to recall ther ewas a pop-up dialoge warning of dire consequences.
Am I going to lose stuff already in either repository (jts or ccm) if I re-register ?

0 votes

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details

Question asked: Aug 26 '11, 11:45 a.m.

Question was seen: 8,203 times

Last updated: Aug 26 '11, 11:45 a.m.

Confirmation Cancel Confirm