Livecode app allow multi-users ?

[teriidb]

HI,
I just read on wiki that Livecode can only create standalone Applications !
I ran a search for multi-users and nothing comes up in that forum...
Is there any way to make a Mutli users app that connect to a web based database or some webapp with LC ?

...
thanks - just discovered LC, ...today

[Simon]

Hi teriidb,
Yes, you can make multiuser apps.
liveCode integrates with sql and mysql very well.

I suggest you read the User Guide completely then;
http://www.hyperactivesw.com/revscriptc ... ences.html
http://lessons.runrev.com/
You will also find the Dictionary an invaluable resource.

Simon

[teriidb]

Tkx Simon for those links.
Ok, what I found is:
- The Dictionary mentions that the User security level properties were "dropped" and only kept for Hyut ttpercard compatibility.
*(hmm, why drop s/t that we can and wil use for LC server managment ?... now we need to reinvent the weel, nop ?)

- I'm not too sure about the Https use - which is also a must - for internet user connection,

This may affect attempts to use this keyword in startup, preOpenStack, openStack, or preOpenCard handlers in the main stack. Once the application has finished starting up, the library is available and the http keyword can be used in any handler.

Does that only refer to Desktop starting app needed to connect to a Web server ?

- As for the Login sample given.
see 36650-how-do-i-handle-user-input-using-livecode-server
Well,hard coding the PW/USER words in the page is the last thing you'd want to teach beginners, right ?

On the other hand I would have expected to find good samples of codes so as to script lookup PW request again the main DB (SQL or NoSQL), Mysql, Postgresql, etc...
Why don't we have sampls to connect to the 5/10 main DB, that we can modify ourselves, isn't it becoz that is among the most complicated things to code well for a beginner ?
...so we're left alone right from the start !
*I'm not even talking about a User-Group LC system managment that should be included to simplify all this
(Did I miss this existing feature ?)

- Captcha is not too be found in the Dictionary and out of context in forum.

Meanin : LC does not provide the necessary code samples for beginner to set up a secure an so common (nowadays) multi users shared database use
*as far as I could see - if I skipped the appropriate info, please point me to that one.,
Since my needs are internet share db with secure access I can not invest my time on a Software that only produces Standalone app although it is maybe very well fitted in doing just that !
I would not call it "for beginners" if we are talking about a good Server/client app "non coding" tool, my views.

Not wondering about strong security just because ppl will be using it inside their intranet is like leaving our keys on the door, hopping noone will want to open the door.


At the era of "Socialise till you drop" available tools/website, I believe you should seriously modernizes some LC feature if you wish to keep attractin public, private and server users.
Cheers,
Terii

[FourthWorld]

- The Dictionary mentions that the User security level properties were "dropped" and only kept for Hyut ttpercard compatibility.
*(hmm, why drop s/t that we can and wil use for LC server managment ?... now we need to reinvent the weel, nop ?)

HyperCard's "user levels" could be said to be related to security only in a very general sense. They're not related to the sorts of security handling we see in modern apps, but are very specific to the way HyperCard worked. If you've never used HyperCard they are of no interest at all.

- I'm not too sure about the Https use - which is also a must - for internet user connection,

This may affect attempts to use this keyword in startup, preOpenStack, openStack, or preOpenCard handlers in the main stack. Once the application has finished starting up, the library is available and the http keyword can be used in any handler.

Does that only refer to Desktop starting app needed to connect to a Web server ?

Without seeing the full context it's difficult to guess what that refers to. My hunch would be that it has to do with the message sequencing at startup, making sure libURL is active before attempting to use it.

What problems have you encountered using HTTPS in LiveCode?

- As for the Login sample given.
see 36650-how-do-i-handle-user-input-using-livecode-server
Well,hard coding the PW/USER words in the page is the last thing you'd want to teach beginners, right ?

On the other hand I would have expected to find good samples of codes so as to script lookup PW request again the main DB (SQL or NoSQL), Mysql, Postgresql, etc...
Why don't we have sampls to connect to the 5/10 main DB, that we can modify ourselves, isn't it becoz that is among the most complicated things to code well for a beginner ?
...so we're left alone right from the start !

Not entirely. While it's true that documenting the entire LAMP stack is far outside the scope of LiveCode's reference materials, the Web is so full of examples for handling those that few have had difficulty finding them.

If you have a specific need with integrating LiveCode in that mix, please describe what you want to do and what issues you encountered doing it and I'll bet we can find a good solution for you.

*I'm not even talking about a User-Group LC system managment that should be included to simplify all this
(Did I miss this existing feature ?)

User account management usually varies from system to system. How Facebook manages such accounts, for example, is very different from how your bank handles them. I don't believe a one-size-fits-all solution is possible.

So again, if you have a specific goal in mind let's see if we can help you achieve that. We'd need to start with a description of the anticipated scale and usage patterns you'd like your app to support.

- Captcha is not too be found in the Dictionary and out of context in forum.

CAPTCHA is not a LiveCode-specific technology, nor can it be used directly in LiveCode applications. CAPTCHA is normally used on web pages, and there are many dozens of such solutions in that category available so even HTML authoring tools don't usually document them.

You can find CAPTCHA's documentation here:
http://www.captcha.net/

Meanin : LC does not provide the necessary code samples for beginner to set up a secure an so common (nowadays) multi users shared database use
*as far as I could see - if I skipped the appropriate info, please point me to that one.,
Since my needs are internet share db with secure access I can not invest my time on a Software that only produces Standalone app although it is maybe very well fitted in doing just that !
I would not call it "for beginners" if we are talking about a good Server/client app "non coding" tool, my views.

True, LiveCode requires coding, so even if it's among the easiest languages to learn it would not be an ideal fit for those looking for a "non coding" solution.

The range of possibilities with DB work are nearly endless. From choosing the DB (MySQL, MariaDB, postgreSQL, MongoDB, CouchDB, SQLite, just to name a few) to choosing the middleware (PHP, Ruby, Node.js, and more) and then whether the client will be a browser (HTML + JavaScript + CSS) or a LiveCode app or something else - too many possible combinations to document. And that's not even touching on the aspects specific to security, which is a deep topic in itself.

Fortunately each of the DB communities has many good examples of interfacing with them from most middleware in most situations, and if you're using LiveCode as the middleware you'll find their database API in the Dictionary.

Not wondering about strong security just because ppl will be using it inside their intranet is like leaving our keys on the door, hopping noone will want to open the door.

I'm not sure what you're requesting here. Of course everyone is interested in security. RunRev doesn't document all possible security methods for all possible options for using other people's software because it wouldn't be a practical goal; if attempted with the nearly-unlimited resources needed, it would at best result in a compendium of materials far too vast for anyone to read.

Learning about specific tools and the security best practices for each is better done in the communities for those tools.

If you have a specific question about LiveCode I'm sure this community would be happy to answer it.

At the era of "Socialise till you drop" available tools/website, I believe you should seriously modernizes some LC feature if you wish to keep attractin public, private and server users.

LiveCode's current Road Map is here:
http://livecode.com/community/roadmap/

Any specific requests you feel should be added to that can be submitted here:
http://quality.runrev.com/

[jacque]

Richard has covered most of the issues, but I just wanted to add that many people are creating LiveCode apps that do exactly what you describe. The problem, I think, isn't in any paricular LiveCode deficiency, but rather because you haven't yet learned quite enough to know what to look for in the dictionary. The "userlevel" is a good example because it has never been a part of LiveCode or any of its predecessors; it is included in the language only for compatibility with imported HyperCard stacks. And even in that case, it does nothing because the level of user interaction a stack allows is far more fine-grained than HyperCard ever permitted. We have complete control over user access without using a blunt tool like "userlevel". (The userlevel never did provide real security, btw, it just limited which controls were available.)

Https is supported. The documentation you quoted is boilerplate that you'll find in every library command in the language. What it means is that you can't call on those commands or functions until after the libraries have finished loading, which makes sense. There's a standard way to deal with that; at the appropriate point in your scripts, you just "send" the command in a few milliseconds. That allows the libraries to load and then your command will execute. From a user standpoint there is no perceptible delay.

We do not hard-code user credentials into web pages; no doubt the example was just to demonstrate a concept rather than a technique. There are many other ways to get user credentials. You'll probably want to provide a form and process that.

It will take some time to acquire all the info you need, but hang in there, it will happen. If you are very new to LiveCode I'd suggest not starting with something as complex as server interactions. Instead try a simple starter stack that will let you learn what's available and how the language and system operates overall.