Developer skriver:
Wouldn't it also be helpful to have the server-side script verify
(validate) the data the swf is sending back up?
That way if someone manually triggered the date, the server would not
accept it because it doesn't match it's system date.
Don.
You have a point. The server
No, I get it. The client and data transfer are insecure.
The hidden information (or the trigger to show the information) should
come from the server not from the client.
Don
On 3/14/2011 3:54 AM, Henrik Andersson wrote:
Developer skriver:
Wouldn't it also be helpful to have the
If the server script knows the acceptable date from the database, it can
just ignore early requests.
Is the problem that Kevin doesn't want the client swf to hold the date
for fear of it being known?
If so, a key could be sent instead that relates to the download date and
stored in the
Thanks to everyone for all of your responses.
What is going to happen, is the application is going to hold a coupon. That
coupon will be retrieved from a database and passed into the Flash
application. I guess as I am writing this, the script will just check the
date and if it is not correct,
Kevin Holleran skriver:
Thanks to everyone for all of your responses.
What is going to happen, is the application is going to hold a coupon. That
coupon will be retrieved from a database and passed into the Flash
application. I guess as I am writing this, the script will just check the
date
Why would you be relying solely on a user's clock? That is most easily
manipulated simply by changing the date and time in their system preferences.
No hacking experience required.
jord
--
Jordan L. Chilcott
Sent from my iPhone... because I can
On 2011-03-14, at 3:06 PM, Kevin Holleran
@Jord - The date will be passed in or retrieved from a script and would be
the server date. My concern was that the date would be intercepted/modified
in some fashion, but since the end result is retrieved from the server, the
server script will just have a check to make sure the date is right to
If I'm getting this straight:
You're asking for a date from the server which you're going to pass back for
approval to show a coupon on the client side app.
Why not just have the server store and send the coupon for the application to
use? The client simply makes one call (two at most... but
On Mon, Mar 14, 2011 at 3:57 PM, Jordan L. Chilcott - Interactivity
Unlimited jchilc...@interactivityunlimited.com wrote:
If I'm getting this straight:
You're asking for a date from the server which you're going to pass back
for approval to show a coupon on the client side app.
Why not just
Unless the client is actually displaying a countdown, it has no need for the
data. All the client needs in this case is a polling mechanism to occur on a
set interval, whether or not it intends to display any countdown down. No data
needs to be pass back to the server. All the client is
Jordan L. Chilcott - Interactivity Unlimited skriver:
Unless the client is actually displaying a countdown, it has no need for the data. All
the client needs in this case is a polling mechanism to occur on a set interval, whether
or not it intends to display any countdown down. No data needs
I work with a team of 3 developers and 4 designers. The developers all
use the FDT Eclipse plugin version, and we use Subclipse to manage our
Subversion repos.
We never commit our project files (mainly to stop noobs from
accidentally changing project settings unintentionally) and all our
12 matches
Mail list logo
