[SOLVED] Questions about context of the app

Hello David,
(I am currently focused on a short projet, so I will come back to the positioning later, sorry for that)

I have noticed something I was not aware of and wonder about the context of the app created with App Builder, perhaps could you shortly confirm or explain the behavior :

I created a java server which opens sessions and creates cookies in a web browser. But if I visit the hosted web app created with App Builder, I can not create the cookie directly in the browser (from the java server). Of course, I can use the internal action SetCookie for that but I was surprised to have to send all the data "over the air" (for example : username + passwordHash -> server -> session cookie -> app builder -> store the cookie -> send the cookie's value to the server as a data, etc)

Perhaps is there an easier way I am not used to ? Many thanks :)

Hello Samuel,

The context of App Builder apps is the client. Our applications are executed in the client side, no matter if they are executed alone in a mobile or desktop browser or after compiled it with Apache Cordova as hybrid applications for Android, iOS, etc. Our applications always run in the client side. You can communicate with the server using HTTP calls or using a WebSocket. Normally we use the first method (HTTP calls) because a WebSocket communication requires an specific kind of server.

This can help you in some way? Please, go ahead if you have any further questions!

Hello David,
Thanks a lot for your quick reply. So if I well understand, I should be able to retrieve the cookie (created by the server) exactly if it was a browser calling the server ?

I will prepare simpler example than my current project. I should do something wrong on that part.

Many thanks :)

Hello Samuel,

Honestly I am not sure what to say, because, when you said the server place a cookie... how this can affect our application? That is, our application main entry point is an HTML file, that certainly are served by some server (well redundancy here), but I am not sure how the server can place a cookie at that point.

In other words, suposing a "real served" HTML (like an PHP script at the server who produces certain HTML code) then yes, that PHP script can place a cookie that we can then read from the HTML produced by the script, once the HTML is parsed and executed from the client side.

But in the case of our AB apps... I am not sure how the "server cookie" can enter in the game here... maybe you can explain me a little more about this!

Anyway, if you are looking for a way to authenticate users probably the cookies methods can be avoided by using HTTP calls. For example, in a more or less big application I am working on right now, the user is authenticated in the initial app's view. The user provide a login and a password, and then the server validate it and give back the user a "token".

Successives HTTP calls includes the user login and the token, so the server can know if the user is already authenticated or not, producing the appropiate response. The best we can do to authenticate the user and in general for our HTTP calls is to use the "https" secure protocol, then the user login and password are sended using a secure connection.

An user without a valid login and password can't login into the application, and therefore can't pass of the first app's view. All others app's views check if the user have a valid token assigned by the server. However, since we are talking about client applications, what happend if someone change the code intentionally to avoid this token check? In fact they can't get a valid response from the server.

That is, such malicious user can play a lot with the client side application's code, however, without a valid login and password they never can obtain a valid response from the server, for example, in the application I am talking about, we can access some user's private data like documents, photos, etc. Without a valid login and password, such information are never returned by the server so we can't view it before a correct authentication.

Please, Samuel, go ahead if you have any further questions!

You are absolutely right David, but in some cases, App Builder is (for me) difficult to insert in some projects. For example, when it sends the OPTIONS request when there is no web server in front but a only a servlet. The servlet waits for the rough data and gets nothing.

But this is out of the scope of that thread and mainly a strange use of App Builder which seems to more respect the standards compared to what I do ;)

Thanks a lot again for the great and quick replies David :)

Hello Samuel,

The app's options are saved in the local storage, which is stored in the client side. The server can't access to that data, except if the application share it with the server, that is, the application always can made has many HTTP calls has needed in order to communicate with the server.

Maybe the point is for you is what a client application can do alone? And certainly they can do... lot of things. However, our applications gain too much when they can connecto to a server because in this case we can store things (in a long term way) or get useful information from the app's server.

In fact everything depend on the application we want to develop. As I said before I am working right now in a more or less grand app (they have now more than 20 views, for example) and they depends in an 100% on the server, not only for user authentication, but because the information which the application provides is specifically served for every user.

By the way this application I mentioned uses a Websocket control to maintain two different kind of chats, between users (in a Wallapop style) and between channels, and they works absolutetly amazing. The application uses the AB provided WebSocket control, but, you know, the key here is the server Websocket that the application uses.

Depend on the application Samuel... we can do several things in the client side (WebExtensions for browsers, for example) but normally our client side applications relies more or less on an app's server to perform other lot of things than we can't do in other way.

[s]That's clear David. Last question, please before to let it down : couldn't it be possible to set SimplePost to send data instead of ContentType: multipart/form-data; boundary=---- ? When I say data, it's because :
- when I use HttpClient with the POST, it sends OPTIONS (I have not found what the Servlet has to reply (I have seen the headers reply you set in the provided php file shipped with AB's examples) ~works great with any server (said for the new comers)
- when I use SimplePost, I get the POST as Method but can't get the content from the Bytes (I should try a lot more)[/s]

Definitively closed : found a way to get the multipart. Thanks David

Hello Samuel,

[s]That's clear David. Last question, please before to let it down : couldn't it be possible to set SimplePost to send data instead of ContentType: multipart/form-data; boundary=---- ? When I say data, it's because :
- when I use HttpClient with the POST, it sends OPTIONS (I have not found what the Servlet has to reply (I have seen the headers reply you set in the provided php file shipped with AB's examples) ~works great with any server (said for the new comers)
- when I use SimplePost, I get the POST as Method but can't get the content from the Bytes (I should try a lot more)[/s]

Definitively closed : found a way to get the multipart. Thanks David

So you discover the Transform option of the HttpClient control? :)

Not at all David, when using the HttpClient I can't enter my scripts because the HttpClient sends the famous OPTIONS instead of the POST.
I am using the SimplePost instead and decode the multipart form this one sends :)
Enjoy your weekend holiday

Hello Samuel,

Not at all David, when using the HttpClient I can't enter my scripts because the HttpClient sends the famous OPTIONS instead of the POST.
I am using the SimplePost instead and decode the multipart form this one sends :)
Enjoy your weekend holiday

So why you don't try with the Transform option of the HttpClient control? We can set this option to "data", which is the default value, and we can receive (at least using PHP in the server side) the values in the POST global variable. We can also set the Transform option to "json", and, finally, we can set the Transform option to "form", which means the data are sended in the same way than other HTML form. Any of both Transform "data" or Transform "form" can be good for you?

Think than the HttpClient control is better than "SimplePost" becuase we have the Success and Error events, so we can react when the HTTP call has been made sucessfully or if an error occur. The "SimplePost" action can be good, but, many times we need to react to the Success and Error events of the HttpClient control, which is something the "SimplePost" action do not offer to us. So my recomendation is to try to use the HttpClient control instead of the "SimplePost" action!

Huh (confused). I will have to retry with a dedicated project but I think if I recall it correctly that even forcing the Transform I had got the OPTIONS (and not having found how to reply it wasn't good). Will let you know for sure ;)

Hello Samuel,

Normally I use the "data" Transform option. HTTP calls in this way are received in the server as expected. Talking about Apache and PHP an script who respond to an HTTP call using the "data" Transform option receive the user/app input in the appropiate global variables: "$_POST" and "$_FILE" (if we send any file with the Input file control).

The script can play with the recieved data and then, everything they "output" (using the "print" or the "echo" PHP stuff) represent the response for the app. For example, supose this PHP script, who receive an HTTP call with the "data" Transform option with a field "name" and the appropiate value inside:

The above script demonstrates how to retrieve an specific value sended via an HTTP POST request using the "data" Transform option. If we use the "form" Transform option we can also access the data in the same way, except in this last case we can't send files using the Input file control, which is something we can do using the "data" Transform option.

Now, what we must do to provide a response to the app? As I said above, talking about PHP anything we echoes in the script is the response for the app. So, for example, in the below script:

... then what the application receives in the HttpClient control's Success event is "Your name is..." and the content of the "$name" variable. The Success event is fired here, because, by default, if the HTTP call reach the resource (our script) then the HTTP code is established to 200, which means a successfully response by the server. So the below code:

... always fire the HttpClient control's Success event and we can look at the response in that event. Again, talking about PHP we can also prepare our script in this other way:

... in this last case, if the "$name" variable is not "Samuel", we use the "http_response_code" function of PHP in order to indicate, in this case, a "bad request" error. Therefore the Error event of the HttpClient control is fired in this case and the response is the string "Sorry, your name is not Samuel", of course if "$name" is not "Samuel", in other case, the Success event is fired instead.

I don't know if this can help you in something or what, because if I am not wrong we are talking about different server software and language, but the behaviour must be the same. Again, if I am not wrong, any server language must provide a way to access the input variables, must have a way to print the HTTP response, must have a way to indicate the status (200, 400) of the response, etc.

Please, if you have any other question, go ahead and I will try to help you when possible! :)

A short and quick and dirty note if one is in need of the same solution :
AB sends the OPTIONS Method with the Access-Control-Request-Headers
don't wrongly reply "Yes" to what ever it asks :) because it specifies its needs with a "content-type, accept"
Only reply : "Content-Type" and a nice "200" status. Then, it will be happy to reply with anything (for example : "application/json")
From that, when you have understood that, App Builder is able to chat with any rough servlet :)

Sorry, I had forgot to thank you again, David, for your detailed information and the great help you provided :)