Automatic login using Authenticator - server restart intermittent problem

[SajidPatel]

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.

[slangley]

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

[SajidPatel]

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]

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

[Constantine]

@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

[SajidPatel · Accepted solution]

@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.