Hi,
I want to create mashup URL which can be accessed without prompting for login credentials. How do we do this? I thought of using application key in URL, but app key can be used for REST API calls only. Is it possible to make initial landing page mashup without login?
Regards
Satish
If it is just a landing page, we recommend you use an Organization and use <server>/Thingworx/FormLogin/[NameOfOrganization]
If you need some 'registration' page, you can still pass in an appkey on the URL but you will also have to set the session (x-thingworx-session) to true, all this can be done on the URL still. Please make sure you set your permissions appropriately in cases like these!
If I use <server>/Thingworx/FormLogin/[NameOfOrganization], then it shows me login page.
But I want to show mashup created containing some information text kind of static web page which will have further mashup application links. On click of these link, I want to prompt for login page.
I also tried using x-thingworx-session=true <Server>/Thingworx/Runtime/index.html#mashup=<mashupname>?appKey=9c00c3c7-4ae6-44e0-b91d-48b6ee481302&x-thingworx-session=true. But no luck!! Am I missing something?
You need to access the Mashups via this the REST interface URL, not via the Runtime URL. It will forward to the runtime URL
<Server>/Thingworx/Mashups/<mashupname>?appKey=9c00c3c7-4ae6-44e0-b91d-48b6ee481302&x-thingworx-session=true
How would you configure the specific mashup to go with the application key for the THING that may have several mashups? Or would you have to delete all the mashups except the one that you want others to see?
Hi Ed, what is the exact use case here. Generally we do not recommend using the app key to give users access to an application. It really should be for like a landing or sign-up or maybe password reset page. And after that if they want to go into the app, they should use a regular name/password
I don't want to give an application key to users. I just simply want to know how a user can access the mashup after it is made and if possible, make it available to the public to just view.
Hi Ed, three ways to give access to users (they of course will need to use a Login and Password)
1. <server>/Thingworx/Mashups/NameOfMashup
2. Add a home and mobile home mashup to the User definition on General Information and send them to <Server>/Thingworx, as long as they are NOT part of the Administrators group, they'll be directed to their home or mobile home mashup
3. Add a home and mobile home mashup to the Organization and direct users to <Server>/Thingworx/FormLogin/NameOfOrganization, the actions are the same as if you had it on the user, but now you get to a nicer login page before the re-direct.
Thanks Pia, - So there is no option of giving public access to a Mashup? The reason I ask, is I like to use some of our projects for public exhibitions and workshops and would like the participants to view the Mashup on their assigned computers. Basically, we could though add a guest account and password and use that?
Indeed a guest login would work or an appkey would work.
But you won't be able to give access to a mashup without any authentication.
This is why people use the appkey, because it can be included in the URL together with the x-thingworx-session to form a single URL vs. making a user put in the Name and Password.
Thanks, PAI. I understand the long app key for many users, but it would be great if each account could tag a app key with a simple word to make that a lot easier to access different Mashups by just changing the tag instead of a long key that cannot be remembered.
Thanks for all the help everyone. Finally was able to display our mashup on a remote computer and a mobile device. We tried a few different approaches and even created a new user and added a home and mobile home mashup to the User definition on General Information but was unable to successfully login (possibly because a valid user name requires "@xxxxx.xxx", not sure.) We tried the following and here's the results.
1. <server>/Thingworx/Mashups/NameOfMashup (worked with a valid user login)
2. <Server>/Thingworx (didn't work)
3. <Server>/Thingworx/FormLogin (didn't work)
4. <server>/Thingworx/Mashups/<MashupName>?appKey=<appKey>&x-thingworx-session=true (worked, no login prompted)
Mostly submitted by Steve Coleman under Ed Konowicz, his advisor.
Hi Ed Konowicz,
I went through 1st and 4th types.
While using 1st type it is not showing any mashups for the user. the user is not included in administrator group.
While using 4th type though I have given appkey it is not showing any mashup. here also user not included in admin group.
Should i go for any other configurations beside this..?
Regards,
Madhu
Thanks Jason. I am able to access Mashup.
My requirement is that I want create a user who has access to only one mashup which is common landing page.
I tried to setup as below.
1. Created a master mashup - MyMaster
2. Created normal mashup MyMashup and assigned to MyMaster
3. Created a User name called "public" and denied all permisions - read, write, execute etc
4. Assigned "public" user to MyMashup and again denied all persmission on mashup level
5. Now generated key for public user
6. Tried to access Mashup. It allows me to access mashup. It should block access to mashup.
Am I missing something?
Thanks
Satish
Thanks for the directions! At least that is one step further to explore.
I'm guessing that since you denied the read permission, the public user can not access the page or services needed to display the page. If you are going this route, you'll need to manage the permissions for the public user so they can only do the necessary functions, and restrict them on the remaining.
Sorry, I did not understand your response.
What My query is that despite denying permissions to "public" user, how I am still able to access the mashup using application key generated for public user.
I tested for every permission read, write etc, but I still can access mashup. In short, does it mean that app key always gives access to mashup ignoring what permissions are given to user.
Please note that the mashup that I am accessing does not call any Things or services, it is purely static page containing label widget with some text.
Can you please help me understand where is problem?
Sent from my iPhone
To remove access to a Mashup you would need to set Visibility permissions. I recommend you read the security section in the Digital guide or Web Based Training to gain a good understanding of the difference between Permission Security and Visibility Security.
Mashup content driven by services is controlled by those services, but static data, just laid out in labels and whatnot... I don't think there is a way to prevent that via permissions. You're not reading properties, or invoking services, on the mashup itself.
But you can do what you want to do with Organizations and Visibility
If you are unfamiliar with the Organizations and how they control visibility, the online help is a very worthwhile read.
To do what you want, you need to enable visibility for the mashup that you want this 'public' user to access, and then by default they will not have visibility to anything else.
First you will need to open the Everyone Organization, and remove "Users" from it.
Then you should make an organization, add one org unit and add your public user to that org.
Finally, go to the visibility section of the mashup security and add that Organization's Org unit to allow visibility access. You can not deny visibility access.
Thank you very much Jason. It worked. Now I can access mashup.
Regards
Satish
FYI - I have latest version of TW 6.0.2
Sent from my iPhone
Another solution to this would be to create a Custom Authenticator. When that custom authenticator's matchesAuthRequest is called, you can verify hat request is for the URI of the mashup that contains the static content. If so, then return true from the matchesAuthRequest method. This will cause the authentication infrastructure to call the Custom Authenticators authenticate method. In that method, do not check any credentials, merely set the user credentials to be a public or guest user and allow the authenticate method to exit normally without error. The request will then continue to propagate the request through the system that will cause a guest user to be viewing the static mashup. Make sure the guest user only has access to the static mashup page or other guest content. You may also want to set the home mashup of the guest user as the static content in case the guest user is used to log in via the standard login prompt. You can then also lock out any access to the static mashup or other content the guest user has access to by simply disabling the guest user. Note that if a request is processed for any other URI, then the Custom Authenticator should not match the auth request (i.e. return false from matchesAuthRequest) and then the authentication infrastructure will water flow to the next available authenticator that can match the request; if none can match the request the authentication handling eventually reaches the Http Basic Authenticator that displays the standard Thingworx browser login prompt.
Thats a good idea.