cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X

Automatic login using Authenticator - server restart intermittent problem

SajidPatel
8-Gravel

Automatic login using Authenticator - server restart intermittent problem

I have an automatic login authenticator based on http parameter as described in my earlier post

 

I am observing a weird behavior sometimes. When the Thingworx server restarts while a mashup (which refreshes automatically at some interval) is displayed, browser sends these following URLs without the custom parameter which is required by the Custom Authenticator to authenticate:

/Thingworx/Resources/RuntimeLocalizationFunctions/Services/GetEffectiveTokens
/Thingworx/Subsystems/PlatformSubsystem/Services/GetAllStateDefinitions
/Thingworx/Subsystems/PlatformSubsystem/Services/GetAllStyleDefinitions
/Thingworx/Subsystems/PlatformSubsystem/Services/GetAllStyleThemes

The issue is these URL's drop my custom parameter, which is used to identify the user to login with. As a result, a login prompt is displayed.

Other times when it works, the URL with my custom parameter gets sent to the Authenticator.

 

How do I control this behavior? Why do these URLs get sent to the Authenticator?

I need to display these mashups on screens that have no interaction interface (no mouse or keyboard), so users cannot login.

1 ACCEPTED SOLUTION

Accepted Solutions

@Constantine@slangley 

I was able to resolve this issue by looking for the 'Referer' header in the HTTP request. The original URL with a custom header was present there, so I could authenticate based on that.

View solution in original post

5 REPLIES 5
slangley
23-Emerald II
(To:SajidPatel)

Hi @SajidPatel.

 

Another option to the one you linked to in your last post is described in this article.  Please take a look and let us know if you have any questions.

 

Regards.

 

--Sharon

Sharon, Thanks for your response.

I missed out on properly defining the problem in the original post above.

Automatic login using the Custom Authenticator is working just fine when the URL is pasted in the browser for the first time. In our case, these mashups are displayed on a TV screen without any input interfaces.

If the Thingworx server recycles/restarts, browser requests different URLs, probably as the session gets invalidated/expires. These URLs as noted in my post above do not include the http parameters in the original URL as a result the Custom Authenticator cannot identify the request as relevant and automatic login cannot be performed. The end result is that - a login prompt is displayed and the mashup ceases to refresh.

 

Is there a way to ensure that all the requests originating from a mashup have a http parameter added to them?

Is there a way to detect a server restart on the client side and resend the original url from browser automatically in such a case?

 

Thanks,

Sajid

slangley
23-Emerald II
(To:slangley)

Hi @SajidPatel.

 

Are you trying to plan for frequent server restarts?  Is there an underlying issue that needs to be addressed to prevent these frequent restarts?  Is this a workaround for another issue?  If the restart is being scheduled, who is handling the login to the server?  We may not be totally understanding your use case.

 

One possibility would be to create a shortcut on the desktop that could bring up the mashup but someone would have to execute it.  Another would be to create a scheduled task if the restarts are being scheduled.

 

Regards.

 

--Sharon

@SajidPatel Those services are required for rendering any mashups. Why don't you just include them as an exceptional cases in your custom authenticator, so that it allows all requests with your special parameter AND those four, even without parameters?

 

Also, if you have a reverse proxy like Nginx in front of your ThingWorx, you might be able to rewrite requests to add parameters to some of them, or (even better) add AppKey parameter to some of them automatically. In the latter case you won't need any custom authenticator anymore. Just be careful with those "public" appkeys to ensure that the corresponding users have only minimal access rights. Servers like Nginx can add/set headers as well as query parameters, and it will be even better, because at least your AppKeys won't be visible in the logs...

 

/ Constantine

@Constantine@slangley 

I was able to resolve this issue by looking for the 'Referer' header in the HTTP request. The original URL with a custom header was present there, so I could authenticate based on that.

Top Tags