Posted by Jerry Stuckle on 04/24/07 01:09

Steve wrote:
> | WHAT HAPPENS IF THIS DOES NOT REQUIRE A LOGIN????? NOTHING WAS EVER SAID
> | ABOUT THE USER LOGGING IN!
>
> imagine if you will/can, that the form carries a tag perhaps identifying
> say, an ip address - i know it's a stretch for you. that would certainly be
> ONE way to marry an instance of data with a browser. input is stored in a db
> with each post/get. when that ip (in this instance) and its data was
> analized, we could then still tell where the user left off - or what the
> next step would be.
>

Gee, and what do you do with corporate firewalls - where all users
inside the firewall have the same IP address? Or users like AOL - where
every request may come from a different proxy - and therefore a
different IP?

I know such an idea is a stretch for you - the fact that IP addresses
are not unique - and not necessarily consistent.


> i can come up with several other matching methods. care for more
> embarrassment?
>

Sure, fire away. You've already made an ass of yourself several times.
Keep it up!

> | > | > note that as i've said. the chances of losing data due to deletion
> is
> | > nil.
> | > | > what you've described is what i also noted. that an update can cause
> a
> | > | > partial loss of data but this only involves the data related to the
> | > current
> | > | > step, and is therefore negliable (with a few caveats).
> | > | >
> | > |
> | > | No one ever said anything about deletion or update. I was
> specifically
> | > | talking about losing the id to the row which is stored in the
> session -
> | > | and the session is lost. Nothing more, nothing less.
> | >
> | > data is in the db. a query will return the correct step that is next in
> the
> | > ladder of steps to get to the top. user logs back in, that step is
> | > displayed. now, pray-tell, HOW IS THE DATA LOST?
> | >
> |
> | ONLY IF YOU HAVE THE PRIMARY KEY TO THE COLUMN!!! IF THERE IS NO LOGIN,
> | HOW DO YOU DETERMINE WHICH ROW IT IS?
>
> yelling is not compensating for your lack of imagination. you keep talking
> about rows. you realize that in a stepped operation, you are not talking
> about just one row of data. each step is probably its own row. i've pointed
> out one way to link a browser instance with data...no reason why it can't be
> tied to all the related rows. as each row is validated as 'complete', we
> simply provide the next set of prompts for input...ad nausium until the
> ladder has been summited.
>

No, but it seems to be the only way you can understand what anyone else
is saying.

I'm still waiting for you to come up with a way to indicate how to
recognize the appropriate row(s). So far you haven't.


> | > | > | > | If you force them to sign in, you could key the data to their
> user
> | > id;
> | > | > | > | then at least it would be saved when the session fails. But
> then
> | > | > | > | they'll have to log in.
> | > | > | >
> | > | > | > and when the user logged in again, since the data is in a db
> rather
> | > than
> | > | > a
> | > | > | > session, you could bring them to the last step they completed
> | > (whether
> | > | > there
> | > | > | > is already some populated data they hadn't completed or if
> they're
> | > at
> | > | > the
> | > | > | > beggining of that step).
> | > | > | >
> | > | > |
> | > | > | And you'll have another session id and another key, unless it is
> keyed
> | > | > | to the userid, as I mentioned above. But he still has to login
> | > because
> | > | > | the session disappeared.
> | > | >
> | > | > yes, the re-log in is a bitch. however i don't recall either you or
> i
> | > | > addressing this problem. let's stick to the architecture for a
> moment
> | > then.
> | > | >
> | > |
> | > | It's part of the architecture - and something the op wants to avoid.
> | >
> | > then wtf don't you just address how he can solve the session problem
> instead
> | > of giving BAD architectual advice...like, 'a db won't get you any closer
> to
> | > solving the problem'. as i've pointed out, it DOES allow for a way to
> | > recover. you just have no idea how to implement a fail-safe.
> | >
> | > get over it.
> | >
> |
> | THEN GET OVER IT! THE ARCHITECTURAL ADVICE IS SOLID! AND YOU HAVEN'T
> | POINTED OUT ANYTHING EXCEPT "IF THE USER LOGS IN...".
>
> yes, MY design is solid. saying db storage leaves you no better off than
> just sessioning the user input is LUDICROUS. btw, that was YOUR advice.
>

As solid as swiss cheese. Glad you aren't working for me.

> and, i've pointed out MANY ways to do all of this. i can pseudo code a whole
> example WITHOUT using logins if that's the only way your pea sized brain can
> conceptualize...solidified as concrete!

You've pointed out NO WAY to do this - other than to require a logon, an
ip address or similar.

>
> | And that does solve the problem of the user having to log in.
>

No, you haven't shown any way to do it.

> hmmm...'that' would be what? sessioning data from a browser where the op is
> KNOWN to have sessions dropped? i don't see how that does anything BUT drop
> the data collected for that user. if you validate and save collected
> information with each steps posted info, you won't even lose a NEW
> record...nor a modified on.
>

And how do you point to the appropriate record?

> | > | > don't couple specific data to a user. we don't have to here. if you
> want
> | > to
> | > | > detect the last thing a user was working on, so be it. however
> nothing
> | > says
> | > | > that has to be that way. you may not even see that as desireable
> though.
> | > | >
> | > | > let's say i work at station 4, take lunch but have left a component
> to
> | > be
> | > | > finish by someone else at station 4. after my lunches i begin
> working at
> | > | > station 5. station 5 is where the build up of astronautic rocketry
> is
> | > | > performed, while station 4 is where legos are put together to keep
> all
> | > the
> | > | > workers humorous and sane.
> | > | >
> | > | > you don't want to tie the user data to a step here. what could be
> done
> | > is
> | > | > allow a login with a selection of stations from which he can chose
> to
> | > work.
> | > | > it would then be appropriate to begin the completion of the most
> current
> | > | > work. that could be automatic, or if multiple components are built
> up
> | > there,
> | > | > they could put in a job id, part id, or any other identifier. having
> | > THAT
> | > | > identifier pull from already SAVED data will solve a bunch of
> problems.
> | > | >
> | > |
> | > | Let's stick to the architecture for a moment then. No one ever said
> | > | anything about changing stations, for instance.
> | > |
> | > | > and btw, NONE of these altertatives i just described are available
> | > WITHOUT A
> | > | > DB. the ONLY thing one should ever need to session is the logon
> | > information
> | > | > of the user. anything else is bad architecture.
> | > | >
> | > |
> | > | If there even is a session login. That part is not clear.
> | >
> | > in the architecture *i've* described, NO LOGIN NEED BE PRESENT. as i
> said,
> | > if you simply select what work you'd like to begin, having a DB will
> allow
> | > you to query DATA for what is left to do for the task. even without a
> login,
> | > identifying WHERE the user is performing his job (answering
> questions/giving
> | > input), you'd be able to give them a LIST of incomplete tasks from which
> | > they could pick.
> | >
> |
> | THEN HOW DO YOU DETERMINE WHICH ROW IS ASSOCIATED WITH THAT USER? HOW
> | DO YOU KNOW WHICH TASKS ARE COMPLETE AND WHICH ARE INCOMPLETE?
>
> ROWS!!! i've made one suggestion already. i'm sure you've built logical code
> before that validates data, right? nothing changes in answering your second
> question.
>

You mean one asinine suggestion which works only if you can guarantee
there is concurrent access - or you require a user to login.

> | > sessions WON'T allow you to do that. a DB will...with great flexibility
> in
> | > ANY context however you implement your access to a process per user. if
> you
> | > remember, you said a db essentially does shit for the op's problem. you
> | > clearly see i beg to differ.
> | >
> |
> | SESSIONS KEEP TRACK OF WHICH ROW IN THE DATABASE IS BEING REFERENCED.
>
> you're not solving anything by using sessions. only complicating minor
> problems like dropped sessions.
>
> | > | > | And if the op isn't forcing the user to login, there is no way to
> sure
> | > | > | way to identify the data.
> | > | >
> | > | > i think i just described a litany of ways in which your assertion
> here
> | > is
> | > | > utterly foundless.
> | > | >
> | > | >
> | > |
> | > | You have? I don't see it. All I see is a bunch of rambling about
> | > | completely unrelated possibilities.
> | >
> | > then you're mind is wholly inable to imagine the TYPE of general
> | > functionality the op wants AND can't draw from you previous EXPERIENCE
> to
> | > correlate different solutions that are applicable to the TYPE.
> | >
> | > intellect is measure by inference and association. are you saying you
> truly
> | > see NO similarities between my 'ramblings' and what the op is doing? if
> not,
> | > i feel for you, bro.
> | >
> | > | The fact is, if you lose the key to your row, you can't access that
> row.
> | >
> | > data is in the db. a query will return the correct step that is next in
> the
> | > ladder of steps to get to the top. user logs back in, that step is
> | > displayed. now, pray-tell, HOW IS THE DATA LOST?
> | >
> | >
> |
> | And your mind is completely unable to grasp a simple concept. If the
> | session is lost and there is no user login, there is no way to reference
> | the row in the table related to this user.
>
> sure there is...use your imagination.
>
> | You have 500 users currently active. Suddenly one of them loses a
> | session. Now - WHICH OF THOSE FIVE HUNDRED ROWS IS RELATED TO THAT
> | USER? THERE IS NOT LOGIN!
>
> not a problem.
>
> | And YES I'M YELLING. You don't seem to grasp even a simple concept.
>
> sure i do. in fact, i've got 6 manufacturing plants with over 400
> workstations total that all have multi-stepped, conditional routing. in 3
> years of it being in service, i've only ever had to go back to add new
> reports. everything else, as i high-leveled here, is sound. AND, the only
> thing i ever session is the user name and password and a security key.
>
> if you can't grasp that this is NOT dependant on logins, you are only fit to
> program in a paper bag from which you cannot break out of.
>
>

Steve,

It's pretty obvious you're a "wanna-be" with no real understanding of
how the internet works, nor do you have any idea how to develop a secure
application.

As I said before - I'm glad you aren't working for me. If you were, you
wouldn't be for long.

But you're a typical troll - all the answers and refuse to see the
weakness of any of them.

What do you have - three months of experience in programming? Maybe less?

As for the "clients" you mentioned in previous posts. Now you've also
proven you're a liar. I HAVE worked for some of these clients. And
none of them would hire anyone with your "credentials".

Get lost, loser.

<PLONK>!


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]