Loading Profile...
AES support, WideString support, HTTP post error with Firefox
Some questions:
- Do you intend to introduce AES encryption?
It is really annoying that I cannot make secure data exchange.
- Another one: when will be wide strings introduced?
Will be sock.httprqstring's type modified to widestring? Other way it doesn't have sense using sock.varbuffrq(2) or sock.varbuffrq(3) if I cannot get access to more, than the first 255 bytes of the variable.
- And a last one: If I make a html form on Tibbo EM-1000 with post method although it works in IE, it won't in Firefox. I know that it is curious but I tested on different PC-s. Please someone try it. (A note: Taiko doc is talking about using post method in "Working with HTTP Variables" section but the source uses "get", same as the provided "08-html_login_1".)
- Do you intend to introduce AES encryption?
It is really annoying that I cannot make secure data exchange.
- Another one: when will be wide strings introduced?
Will be sock.httprqstring's type modified to widestring? Other way it doesn't have sense using sock.varbuffrq(2) or sock.varbuffrq(3) if I cannot get access to more, than the first 255 bytes of the variable.
- And a last one: If I make a html form on Tibbo EM-1000 with post method although it works in IE, it won't in Firefox. I know that it is curious but I tested on different PC-s. Please someone try it. (A note: Taiko doc is talking about using post method in "Working with HTTP Variables" section but the source uses "get", same as the provided "08-html_login_1".)
I’m curious about your solution.
1 person has this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
The best answer from the company
-
Quite a few questions here. Let's see:
AES: There will definitely be an option for a secure data exchange. It's right at the top of our development priorities. But I don't want to downplay the amount of time and effort it takes. So -- it will be done, but I can't make any promises with regards to times.
wide strings: This is directly from our TIDE lead developer:
He is mixing two things in one:
1) Widestring is UNICODE string (which uses 2 bytes for each characters, so-called wide-chars). that's critical for asian languages, but there are no plans to support that in near future.
2) String that will be longer than 255. That is indeed a known limitation at this time, and there are definitely plans to lift it. We might introduce another type like longstring or stringex or buffer which will has no limitation, or simply modify ALL strings to support 65536 characters, which should be enogh for most people who are stuck now.
This is a matter of firmware engineering, and once more, I cannot commit to a specific deadline.
form bug: This is apparently a known issue, and our Taiko guys are working on a fix. It's a firmware issue. Is this critical for your application?
The company says
this answers the question
-
Inappropriate?Quite a few questions here. Let's see:
AES: There will definitely be an option for a secure data exchange. It's right at the top of our development priorities. But I don't want to downplay the amount of time and effort it takes. So -- it will be done, but I can't make any promises with regards to times.
wide strings: This is directly from our TIDE lead developer:
He is mixing two things in one:
1) Widestring is UNICODE string (which uses 2 bytes for each characters, so-called wide-chars). that's critical for asian languages, but there are no plans to support that in near future.
2) String that will be longer than 255. That is indeed a known limitation at this time, and there are definitely plans to lift it. We might introduce another type like longstring or stringex or buffer which will has no limitation, or simply modify ALL strings to support 65536 characters, which should be enogh for most people who are stuck now.
This is a matter of firmware engineering, and once more, I cannot commit to a specific deadline.
form bug: This is apparently a known issue, and our Taiko guys are working on a fix. It's a firmware issue. Is this critical for your application?
The company says
this answers the question
1 Comment Add a comment
This answers the question
-
Thanks for the fast and precise answers. (Note to widestrings: you are right, I meant longstrings.) I hope the planed improvements will be available soon. -
Inappropriate?Some note to AES: Please be careful to remain compatible with OpenSSL.
Recently I had problem with different AES implementations.
Tibbo AES solution will work easily, if I can encrypt/decrypt TCP data flow with OpenSSL. E.g. "openssl enc -aes-128-cfb -nosalt -in inputfile -out outputfile -pass pass:something"
I’m looking forward to AES implementation!
1 Comment Add a comment
This answers the question
-
Good point, thanks!
EMPLOYEE
