When you login, you put at least a login in session (or a token) +
cookies in options, and of course you need to refresh the whole page
to do so. Otherwise, document headers are not updated and you'll find
nothing in session, even if successfully logged in.
R.
> --
> You received this message because you are subscribed to the Google Groups "iPhoneWebDev" group.
> To post to this group, send email to iphone...@googlegroups.com.
> To unsubscribe from this group, send email to iphonewebdev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/iphonewebdev?hl=en.
>
>
--
Kinds Regards,
Remi Grumeau
Login is a pretty much serverside process, frontend doesn't have so
much to say here...
> Surely there is a simpler way to handles this with MVC. I have even
> tried response.redirect to the main page but then it loads the main
> page again insided the current toolbar. Please help.
Which is the actual normal process. A login page with a form, that you
submit via JS or plain POST submission... and detect if login/pass is
ok server side. If not, just render the form again with a clear prompt
message ("wrong pass", "no account with this ident", ...) and if
login/pass is ok, redirect to the "index" of your app. On load, this
"index" should normally test session if ident / token is ok and render
your app (and if not, redirect to login form).
If you deal with session or cookies (or anything in headers), just
forget about ajax form submission ...
R.
Have you looked at the links on this page:
http://code.google.com/p/iui/wiki/iUIWithASPNet
-- Sean
-- Sean
To me, a mailing list main goals are to discuss issues / bugs or project related choices we want to ask community pov. It's also kind of a getting started help for newbies (where a good doc + faq could do a good job too).
Community, help & sharing in mind around the project.
Not being a 24 / 7 free tech support service (at least not in my mind)
R.
>> Next step stop using IUI, I guess and go with something else.
For your project, we told you twice you can't login via an Ajax call
since a session (server side) needs user browser headers to refresh.
iUI has nothing to do with that (best example:
http://m.pocket-locator.com, powered by iUI, with a login/pass
pre-home.).
Of course, if you switch to iwebkit or webapp.net you'll won't have
issues with that since they don't provide any transition or ajax form
processing. But you'll have similar "issue" with JQTouch, JQuery
Mobile or Sencha with .Net or PHP server-side.
R.
--
Kinds Regards,
Remi Grumeau
I think this place is (or tries to be) what you describe. But there are
two limitations you will find: (1) people are volunteering their time,
so may not be able to dive into your particular issue as deeply as you
like and (2) people are not experts on server-side technology such as
ASP.net MVC.
When troubleshooting potential iUI problems we always ask people to try
to reproduce the problem in as simple an example as possible using
static HTML files.
Have you tried asking for help on any ASP.net MVC forums?
-- Sean
I have built an iUI app that used Ajax for login. So, It is possible.
In the case of this particular app, all requests to the server were done
with Ajax, so I was able to store the login information using JavaScript
and made sure to add it to every Ajax request.
It really depends upon the structure of your application and the way
your server handles authentication.
-- Sean
A suggestion. Try starting an entirely new post (with a subject line
like "how to handle login with iUI or similar framework"). Try doing
the following:
1) State the big picture problem you are trying to solve. (There may be
more than one solution to your problem) There is definitely more than
one way to handle login with iUI/Ajax. You should include any
requirements your server has for login, but please state them in terms
of HTTP rather than ASP.net -- that will allow many more people to
understand the problem and offer help.
2) Provide detail about one or more attempted solutions you have tried.
Provide a link to a sample installation of the code if possible, so
people can look at it in their browser (and possibly use their JS
debuggers,e tc)
3) Try as much as possible to separate the client side issues from the
server-side issues. (Nobody here seems to know much about ASP.net)
-- Sean