I have a login screen that works fine except that the value for userGuid returned by my PHP script can not be referenced as the merge field [userId] later on as would be implied by the documentation. PHP code snippet to set userGuid: $result = '{result:{status:valid,userGuid:' . $sellid . ','; $result .='userDisplayName:' . $sellname . ',userEmail:' . $sellemail . '}}'; URL to use userId: http://www.now-hot.com/mobapp.php?goto=termserv.htm&appid=[buzztouchAppId]&userid=[userId]&model=[deviceModel] The userEmail passed in thru login does show up. Am I missing something here or is this not working right? Any help is appreciated.

Part 2 Given the URL above, here is the PHP snippet to get the info: $goto = $_GET['goto']; $appid = $_GET['appid']; // The App Id from buzztouch control panel $userid = $_GET['userid']; // The Unique Id of a logged in user (if the app uses login screens) $model = $_GET['model']; // A string value controlled by the device manufacturer. $userid ends up as empty ''

It looks like you have the idea. a) Look at the console when you use the login screen (in Xcode) so you can see the actual URL that is used after the values are merged. This is important to make sure the id / password are sent. I'll bet the [userId] field you have in the URL should be [userLogInId] b) Replace [userid] with [userLogInId] and I'll bet it works.

Thank you very much. Case closed. Using [userLogInId] instead of [userId] worked. (Watch out for the capitalization!) Is it safe to assume that [userLogInId] is cleared when the buzzTouch app Logout button is tapped? It looks like it is cleared in the code and this would give me a capability to sync the app and host when the app interacts. Unfortunately I can't set logged out status in the app from Javascript on an HTML page. I would suggest the documentation on Available Merge Fields be updated to include this and any other changes. What goodies are we missing out on? It would also be nice if the logout button sent a message to the host as well, but I know you guys are busy with bigger things. Thanks again and best wishes for buzzTouch's future. Great stuff.

Sorry, double post cleared. How do you delete a post?

Hi in TX: Our ghetto 'forum' doesn't allow for deletes. I know, I know, we'll get there. Send a logout message to host - this makes perfect sense. Added to the list. When I looked at the login screen to find the earlier answer, if you see a reference to [userId] (as compared to [userLogInId] for the login screen, I'll need to fix it. Oh, wait, I know what you mean... In the merge fields, you can merge [userId] in any URL, on any screen, for images, wepages, etc. This is different than the login authentication idea. This is AFTER the user is logged in. The idea is that you can add the [userId] merge field in any URL to then pass to your server, like to serve that user custom content, etc. I see where this could be confusing! I just removed the other merge field information on the login screen so it's less confusing. Great find.

Few forums allow a poster to delete. Only admin/moderators usually. No big thing. I was referring to the v1.5 documentation under Available Merge Fields under Data URLs and Merge Fields. There is no mention of [userLogInId] as being a merge field but [userId] does show up and that's why I used it. I must be missing something here. So, now I'm confused. What you describe in the last paragraph was what I was trying to do. Use the Login screen to get logged in and then pass the [userId] along with other parameters to the server on CustomURL screens. I don't get any value for [userId] sent from the phone even after I have logged in but [userLoginId] comes out fine. As long as you're adding things to the Login screen list, add an MD5 hash (or some other mangling) of the password so the bare password isn't transmitted. I understand that an intercepting hacker could pass the hash without the password but at least I wouldn't be leaving someone's password in the open. On the server side, the MD5 is stored so if the server gets hacked it doesn't divulge anything there either. Maybe just some instructions on how to MD5 hash the password in buzzTouch would suffice. Thanks again for the help.

It sounds like you understand this mostly. The [userLogInId] field is ONLY used on the login screen itself, no where else. The [userId] merge field can be used in all other Data / Image URL's. If you're logged into the app, and the [userId] field isn't being merged into your URL (where you included the placeholder) I would be surprised. I just did a few tests and did see the userId (the actual useri id after logging in) is being merged. Maybe look at the console when one of your screens makes an HTTP request for data. The console should show the finalized URL after merging the userId. One more thing, the userId that's merged is the one that's returned from the login authentication script on your server (the value in the JSON data). I wonder if that's not being returned? MD5: Totally agree. We don't encrypt the entered userId / password pair entered by the user, on the phone, before transmitting for a few reasons. Mainly.... a) Most of our site visitors don't fully understand this process and we end up doing lots and lots of advice giving, training, support for folks that really shouldn't be working with the login process anyway. This isn't you but you can well imagine the number of folks that use our free tools that simply don't understand. b) Apple. When you submit an app for approval, they are very very critical about 'encrypted data' (many countries have special rules about this) and as such leaving it plain prevents users from having to yet again understand something complex. For sure you should engineer a more sophisticated approach for an enterprise or highly sensitive deployment. Sounds like you did the right thing on your backend but now just need to work out a strategy on the phone end. Again, lots of ways to do this, all require a deeper understanding a bit of hacking.

Well I've got something broke somewhere then, because when I use the merge field [userLogInId] in the URLs (several) everything is fine. When I use [userId] as a merge field I get nothing. I've verified the results on the console and can send them in if you like. According to the console, the sent and returned JSON data at login is good. Maybe I should download the source again and recompile. BTW, good point about the app store and encryption and foreign countries. Never occurred to me Apple might be picky about hashing, though. The banks use MD5 all the time for authorization and settlement (as I found out on this project) and I would have done more on the iPhone if I had easy access to MD5 routines. Gotta have it for mobile payments. As it stands now, I have to do the MD5 work on the server instead. Better support for AJAX would be nice too to cut down on traffic to the server and provide partial page updates. In time it will come, I guess. Cheers.

I downloaded the source again and recompiled and I have the same results - [userLogInId] returns the value from userGUID and [userId] returns an empty string. Would just feel more comfortable using a documented feature.

You might want to check this line in BT_screen_settingsLogIn.m //save prefs [BT_strings setPrefString:@userGuid:[[jsonData objectForKey:@result] objectForKey:@userGuid]]; Should it be: [BT_strings setPrefString:@userId:[[jsonData objectForKey:@result] objectForKey:@userGuid]]; Just a guess. Must not be very many folks using the login screen.

Hi all, I've been using merge, works for me. Here is the details: - Using userLogInId - used in both DataURL and JSON menu strings. For example in DataURL, I have unique BT_config.txt files for each of my users, re-named as follows: [email protected] [email protected] (etc) BT.TXT So, the user id (email address) is embedded in the config file name. My configuration data URL string is set to: www.mydomain.com/BTfiles/[userLogInId]BT.TXT So when mary is logged in, she sees content appropriate to her because it's using the [email protected] file to provide configuration data. When joe is logged in, he sees his content as specified in the [email protected] file. When nobody is logged in, logInId is blank, so the default config file name used is BT.TXT. Same approach could also be used easily to change to different directories based on people's email addresses, or to go to JSON sub-menus based on email. Of course, you must instruct your users to hit the refresh button after they log in. That is what causes their new config file to load. Finally, the only glitch I've found is, if somebody logs in using UPPPER CASE for their email address, the upper case will be saved into the LogInId variable, and since file names on servers are case sensitive, this will cause the config files to not be found. If I wasn't so lazy I'd normalize all the merge fields as lower case, so this is never a problem, but for now I just tell people to remember to use lower case when logging in. @Codebuster I'd be happy to help if I can. Cheers, T

@ThomasB - clever usage of login screen. My app is working fine when I use [userLogInId] just like you. But that is not what the help documentation says to use. If you use [userId] after login like the documentation says, you would have had problems as well. Look in the BT source code as mentioned above and you'll see the problem. You'll also find the exact location to address your UPPERCASE problem. What irony. Can't seem to get buzztouch to acknowledge that the docs and code are out of sync. You're using an unsupported feature that may change in the future when they correct the code. I don't like using undocumented features because they tend to disappear. I prefer the system work like the documentation says or change the documentation to work like the system does, but sync them up. If you want to help, contact buzztouch and let them know there is a problem with the way they store their strings. I know they have bigger fish to fry right now but I spent several hours debugging this one and kind of got a cold shoulder.

@CodeBuster : Cold shoulder? I'm confused. The documentation for the login screen appears right. There is a difference between the [userLogIn] placeholder in the login authentication URL, the [userId] placeholder in dataURL's used to provide data to different screens and the userGuid value returned from the authentication script. It sounds like you understand this right. Cool. Which part of this in the documentation would you change? I do see an issue in the BT_screen_settingsLogin.m file like you pointed out. The code snippet you posted where it saves the returned results from the login script using the setPrefString does appear WRONG. I think you're remark about other folks not using this feature, and not noticing is also correct. I added this to the list of updates (this is an easy fix) the other day and will ensure that it gets updated.

@Codebuster, Hey, don't sweat it. This is a great product, some really breakthrough, new work and it's free! The buzztouch folks are working really late hours on this, they are really making huge strides. Then come here into the forum late at night and answer questiosn as much as they can. You just kinda have to go with the flow :) For those of us who are buzztouch evangelists, we don't expect perfect documentation, because the code is evovling so rapidly (and in a direction that so immensely valuable in the long term). It's a fast-moving beta product. So we pretty much don't worry about the documentation. The forum, and the discussions here, are where we get our information and our tricks. Much better than documenetation in my opinion because it's dynamic and we have dozens of creative souls who are posting their tricks. And it's free! So just enjoy it for what it is. If you are building apps that need better documented code, then for sure you should find a different product that is better documented. I have been in that position many times over the years and I totally understand why you would want that. And...thanks for bringing up this topic and posting those code snippets. This is a feature that I'm going to be using a lot in the future so this thread is very good to see.

The documentation for the login screen appears right to me as well - works as advertised. And I am aware of the differences between [userLogInId] and [userId] and their usages. Painfully aware because [userId] is a dud. As far as the documentation changes: Click 'help' at the top of the page then click 'Documentation' then click 'Data URL's and Merge Fields'. Scroll down to: Available Merge Fields * [buzztouchAppId] This is the App Id from your buzztouch control panel * [buzztouchAPIKey] This is the app API Key from your buzztouch control panel * [screenId] The unique id of the current screen (useful for determing the app context) * [userId] The Unique Id of a logged in user (if the app uses login screens) * [userEmail] The email address of a logged in user * [deviceId] A globally unique string value assigned to the device. * [deviceModel] A string value controlled by the device manufacturer. * [deviceLatitude] A latitude coordinate value (if the device is reporting it's location). * [deviceLongitude] A longitude coordinate value (if the device is reporting it's location). The entry for [userId] is incorrect. [userId] is empty when used because it is not set when userGuid comes in. userGuid is set instead as evidenced by the code snippet above. [userLogInId] is not listed although it is available and is what I and ThomasB are using. This is an undocumented feature that will be fixed in the future and if you take [userLogInId] away then that will break my code and ThomasB's as well. That's the problem with this one, how is the fix going to work. My preference would be to keep [userLogInId] and add it as a documented feature to the above list and actually replace [userId]. Then you don't have to change any source code and you won't have any confusion as to which merge field to use. Further down on the same page is this: ------------------------------------ Merge Field Usage http://www.mysite.com/localrestaurants.php?deviceLatitude=[deviceLatitude]&deviceLongitude=[deviceLongitude]&userId=[userId] turns into: http://www.mysite.com/localrestaurants.php?latitude=38.4456&longitude=-102.3444&userId=00000 ------------------------------------- Perhaps this worked at one time, and this very example is what hooked me into trying buzztouch because I'm doing something very similar with geocoding and userids, but it also put me onto the problem. [userId] cannot return '00000' as the BT source code is written and I couldn't get it to return anything either. So I dug into the BT source code (very well structured and actually quite easy to find your way around I might add) using Xcode, found the problem and published a solution to help others that may be having similar problems. Is there another, preferred way I should have approached this? If so, please point me to the problem reporting system or whatever method I should have used. I love you product and have high hopes for it and trying to do the little things I can to make it better.

Yep, all makes perfect sense. Speaking for myself, this is a great thread and much appreciate your input on the code. Your comments on UserId are quite accurate...so from here on out I think the thing to do is use [userLogInId]. I wouldn't be surprised if BT Server 2.0 has more functionality in this arena, which might include your fixes (and hopefully the uppercase-lowercase fix.) As far as problem reporting systems...unless mistaken, I think this is it! (the forum!). By the way, it is not at all unusual for BT users to write up little mini-tutorials on whatever code they discover. So if you want to do a tutoroial, I'm sure we'd all love it.

Awesome post. Thanks tons. The update for the trouble with the userId not being saved after the login results are returned should roll out tonight sometime (updates are usually done around midnight). Stoked to have your help.