A changed Windows authentication to Forms authentication. Using the following example.
I added a user with Web Site Administration Tool. Finally I added this user as Site Collection Administrators and the user is recognized by SharePoint. Happy with that is started my WSS site in the browser but when I try to Sign in using this sign in form it is not working. Returns to this form after the submit (//spvm:100/_layouts/login.aspx?ReturnUrl=%2f_layouts%2fAuthenticate.aspx%3fSource%3d%252f&Source=%2f)
I have been scanning my Eventviewer but no succes for any comment what tells me what I am doing wrong. Maybe some of you guys can help me out?
Once you are redirected to this page, try navigating to http://spvm:100. Sometime I get this kind of case where I move make to the root, then it works. I really didnt know the reason why sometime it behaves like that.
I had the same issue. I found that something was wrong with my browser's settings. I tried to log in with another browser (Firefox) and that worked for me.
I don't know yet what was wrong with my IE7's settings, on another machine I could log in to a forms auth site without any problem.
Related
We are building an iOS app where users are asked to sign in with Instagram.
The flow is as follows:
we open an Instagram login page in a web view,
user inputs his login and password,
then in most of the cases he is asked to verify his account by getting a code by email or phone and entering it on the next page,
after doing so, Instagram app opens in a web view and does not redirect to the app.
I saw a similar issue here, but did not find it usefull.
Maybe you have faced such an issue before and can somehow help.
Thanks!
This is probably ancient history by now, but in case someone else is stuck with the same problem you may want to have a look at your universal-links.
Supporting universal links for the redirect_uri turned out to cause sporadic failures for us.
I followed the tutorial page on doing the basic Facebook authentication and login, but it seems to create a redirection loop.
The parent page sets up a listener which, on authResponseChange, redirects to a handler.
The handler then gets the token and redirects back to the parent page
Which then sets up a listener, logs in, triggers authResponseChange and redirects to the handler. Etcetera...
Have I misunderstood something, or is this a bug or expected behaviour? I need to find a way to NOT have this happening.
Secondly, the documentation for 'Using Facebook & ASP.NET Membership for Authentication' is obviously not ready, but I would appreciate some pointers on how to do you would advise doing it.
EDIT: I presume that both of these issues would be fixed with the same solution, ie - getting the handler to redirect to a new page which creates a new ASPNET Membership user based on the facebook credentials - however I am unsure how to do this as the documentation for this section just says TODO. Any pointers? Would you need to just extend the Profile system to store the access token and facebook ID ? Or am I on totally the wrong track?
On another demo here some folks said it was a problem with ie9/chrome and cookies on localhost. Pointing to 127.0.0.1 and run it on iis it fixed the issue for me.
I have developed a face book iframe application in .net c#.First time when user access iframe application
it shows this window but it should ask for permission & allow user to access my app.
When i click go to face book.com it shows permission window.after that when i choose allow its redirecting me to my canvas URL out side the face book.when i try to access 2nd time its working fine.The issue is that for every first time user who want to access the app ist shows the existing window.Please help me to solve this issue.
Thanks
I figure it out.#pastylegs said right.Thanks for your answers.Let me elaborate it.Most of developer just redirecting to specific url so you have to redirect on top window.
1)if you are using a tag so use target=_blank.
2)If your are using any other thing to redirect in any technology so just use
top.location.href='" + codedataurl + "'
where codedataurl is your facebook authentication url which contains client id,redirect url & all.
I hope it will help you guys.
Thanks
If you are using iframes, you need to make sure that when you redirect the user to the authorization dialog, you do so on the top window of the users browser. You can do this using javascript (instead of just a redirect URL).
http://developers.facebook.com/docs/guides/canvas/#auth
Maybe this is the problem?
I'm facing an extrange behavior in my Sharepoint 2077 farm:
We have configured windows integrated authentication with NTLM, and all clients authenticates correctly to the portal.
When they proceeds to "login as" diferent user, it seems to be all fine (appears user name in top of page) , but internally the page user is the old user. I know this because I have a customized web page that reads page user name and print it to the page.
after some refresh or waiting some time, the current user is applied "internally" too.
Do you know is there is any configuration option for avoid this delay?
Many thanks in advance,
any help would be appreciated.
solved there:
http://support.microsoft.com/default.aspx/kb/970814
I have a local site (IIS6, although similar issue with a totally different site using IIS5.1) which uses integrated windows authentication, from what I can tell - using IE7 if a user enters the URL into the address bar, everything works OK and the user is logged in automatically. However, if the user clicks on a hyperlink within an e-mail (using Outlook), the site opens but the user gets a login prompt - when details are entered everything then works fine.
Can anyone explain why this is the case? I should say it's actually very temperamental, sometimes the above occurs, sometimes it doesn't... any help is appreciated.
cheers!
Are the urls of the two cases identical? If there is a . in the url, IE will not attempt to pass the user credentials to the site, and will therefore not automatically log you in.
Example: http://mysite/page.aspx is different from http://mysite.domain.local/page.aspx, even though they might point to the same server.
If Outlook is launching using the domain.local, you will get the behaviour you describe.