Community Tip - Need to share some code when posting a question or reply? Make sure to use the "Insert code sample" menu option. Learn more! X
Hi,
I have same user, home mashup and organization on server1.cloud.thingworx.com and server2.cloud.thingworx.com thingworx instance.
When user login from server1.cloud.thingworx.com/Thingworx/FormLogin/Organization it should login and redirected to server2.cloud.thingworx.com/Thingworx/Runtime/index.html based on some data table field.
Any idea how to achieve this?
Thanks
Solved! Go to Solution.
Hi @jmehta my understanding is that redirects are handled by Tomcat configurations, I'm not aware if there is any possibility to transfer DataTable data after the user has completed the login process and is already in Server 1.
Sorry i am not really clear what exactly is your use case? I suppose it could be much easier to setup filters via the Tomcat to redirect users to specific URL patterns. Would help to have more context on this actually.
Hi @jmehta my understanding is that redirects are handled by Tomcat configurations, I'm not aware if there is any possibility to transfer DataTable data after the user has completed the login process and is already in Server 1.
Sorry i am not really clear what exactly is your use case? I suppose it could be much easier to setup filters via the Tomcat to redirect users to specific URL patterns. Would help to have more context on this actually.
Hi @supandey, thanks for reply.
The use case is user will login to server1. After login we have to check whether this user's things is on server1 or not. If the user's thing is on server1 then show the Mashup. If user's thing is not on server1 then we have to redirect the user to server2. The user should not login again on server2.
Wondering if this kind of use case could work with the custom authenticator. Also just a side thought on performance : may be such a use case also impact login time for the users, since at certain point you may have hundreds or even thousands of things which will need to be checked.
Would it not work to have these entities segregate based on projects/organisations? In that case you could use the different form logins for the users to direct them to different servers or mashups
Why not just let the user stay logged in to server1 and just query over to server2 to get the thing's data? You need one service that calls GetImplementingThings on server1 and server2, but for the call to server2, you'll just construct it as a REST call. If the thing exists in the result set from server 2, then just call another service who's responsibility is to make REST calls to your other server. Set up your service properties to include service name and an infotable of that services required parameters. Then use that data in your service to dynamically construct your REST calls to the other TWX server.
Thanks @wposner-2 for a nice suggestion!
It may be the way of doing it. But there will be several issue like in UI where all the things and its data should be visible. The end result will be all the things will be visible on server1. It requires lots of changes, for example any change in thing you have to find the location of thing (server1 or server2), get the things from both location, join infotable then show to UI and so forth.
Feasible way will be try to keep all the things on server1 and forget about server2 :).
What I've suggested for you is pretty much the only option if you have specific instances of things that live on different servers. I'm having to design the exact same functionality for a global implementation that has regional regulatory data restrictions. Regional users will log in to their instance, but US users will need to be able to find any "thing" regardless of region. If you design your query service correctly and implement a little architectural overhead, you can easily scale horizontally and never have to worry about making any further changes. You can also create an index datatable that knows what things exist on what instances so you don't have to query the instances directly--query your DT, find the thing/instance location, then issue a REST API call to that instance (provided the thing isn't on your current instance).