I have this problem on my phpbb board that sometimes when two users post in the same minute their posts are displayed in the wrong order. It even happens that the first post is already visible before the other user decides to reply, then when the user has posted, the post is displayed before the previous post.
Some users also report the forum 'clock' to be two minutes behind the real time.
I can't find a similar problem anywhere on the web. Does anyone have a clue what might have caused this problem?
Thanks.
I took this up to the host, although they denied it was a server time problem, it was fixed after I reported it.
My guess is that the problem was caused by a synchronisation issue in the server-cluster (and that the host didn't want to admit it). The problem first occurred shortly after a (problematic) server update.
Related
I would like to ask this question to developers who have a good sense of design. I see that whenever a website uses a popup box for their login page, they will always post and then redirect to the next page whether it be content or a dedicated login page for an invalid login error.
I have a client who has been asking to cut out as much page refreshing as possible, including the login function. They would like to see the login error appear on the login popup box without a page refresh.
I have not noticed a web based businesses do this, so I'm wondering if there's a valid reason to avoid this. I personally think that a page refreshing allows users to recognize their input has been registered and the next page appearing will be a solid response to their action either good or bad.
Having no refresh and expecting the user to notice that some error text has appeared seems like a bad idea?
Notes
The question is most likely more appropriate for https://ux.stackexchange.com .
You can find a lot of stuff by searching "ajax logins" in a search engine
There already is this question that might indeed be a duplicate of this one. Since I was not sure and I had already wrote most of this answer before finding that I post it nonetheless.
The title ought to be changed to a question (maybe something like "Is it a bad idea to use ajax to return login errors?").
Actual Answer
In my opinion ajax logins could indeed make less clear whether there really has been a successful interaction with the server or not.
Some ideas to improve it might be:
to include the time of the login request in the error message
to explicitly assure in the error message that the credentials have been received and checked
to be sure that this error does indeed only occur after the credentials have been determined to be not valid (and not because of problems with scripts or the network, for example).
A good way to ensure this might be to have the server always send the full text of the error, rather than a code that selects a message stored in the page source (and to be careful its caching).
This becomes relevant only after the user has been using the site for some time, of course (and has incurred in the error and verified that it was indeed due to a mistake on his part).
to use some animated feedback to highlight the dispatch and the reception of the reply to the user. As with the text you should ensure that the animations do not give (too) incorrect indications.
Basically these suggestions would be applicable to any ajax form entry, but they are more important for logins because:
in this context it's a lot easier to make typing mistakes (in the typing of the password)
and mistakes have a drastic, immediate annoying outcome: the inability to authenticate and the necessity to input again the entire password
And so uncertainties on whether the input has really been received and processed are a lot more bothering.
All in all anyhow it's pretty complex to do this well, with both an appealing appearance and a reassuring feedback.
The ones ajax logins that I've incurred into did not do a good job (I think I have indeed experienced false login errors with them).
You can find several ajax login frameworks/plugins by searching for "ajax logins". I have not looked into any of them.
Frustrating issue with attempting to use REST to login to the BIM 360 Field API, it was suggested that to use the postman application in order to ensure that my code wasn't an issue, however I'm now getting an unauthorized error, this has been attempted with an admin account and a developer account with the same response (login details are definitely valid), I was wandering if anyone has encountered this problem before or has any idea how would go about getting past this, I need to get the ticket response in order to go any further with developing an application for this, I'm already in contact with someone from Autodesk but due to timezone differences responses are difficult!
I've attached a picture to highlight the simplicity of what I'm attempting to do with no joy!
Thanks in advance
Dan
In case somebody else hits the same issue, FYI -
Dan and I looked at this issue, and we learned (in a hard way) that the base URL for BIM 360 Field in European region is:
https://bim360field.eu.autodesk.com
Notice "eu" in the URL. In the U.S., it is https://bim360field.autodesk.com
I wrote a post about this, too, for future reference:
https://fieldofviewblog.wordpress.com/2016/08/18/base-url-for-bim-360-field-in-european-countries/
I also found it worked when I used https but not http although the examples in the help use http.
Background: I'm trying to log into an HTTPS site with my valid credentials, navigate to a page that has a frequently updated list, and then scrape the list.
I was using code someone else wrote, which worked until a few weeks ago. I am new to this, but even i can see that the code was not very good, so i am trying to rewrite.
First I log into the site and create an tunnel. Then I move to the page where my list is and grab the list, etc.
Here's what's weird. The login fails every time, until I turn on Fiddler. With Fiddler running it succeeds every time.
Any idea about why this would happen and how to fix?
Many thanks.
I got it working!
For anyone who finds themselves in the same situation (I've seen a number of posting of similar questions - but the answers hadn't worked for me, so I expect I am not alone), I eventually saw that I needed to set the security protocol to TLS. The specific syntax I used was:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;
The setting needs to be specified before the Httpwebrequest get or post event occurs.
If you have a similar problem, I hope this helps.
I had an invalid "User-Agent" header. It contained invalid characters (ä, ö, ü).
I'm using Graph API to get posts that a user is tagged in, and then issuing a like on the posts by POSTing to [post_id]/likes. However, even though the post obviously exists, because I was able to retrieve the post_id, when issuing the like, the following error is encountered:
(#100) Error finding the requested story
I find that this seems to affect only posts with post_id in the format of [user_id]_[post_id].
Is this a known bug or is there a workaround?
an old question but might help someone.
For me the issue was that if the post privacy is public then you can access in the way you doing and it works fine, but if the privacy has some custom setting then you will get the above mentioned error.
The fix that worked for me was to get the permission "read_stream" from the user, if user gives you this permission than you can use the post in similar way as you are doing (i.e. [post_id]/likes )
This question belongs on meta. I'd ask there, but I need to log in to ask a question, and that's where my problem is :)
I have an ID on BlogSpot.com (that's the Google Blog thing). I'm pretty sure that's my credential for this here site. However, I can't use it to log in to superuser.com (where I originally wanted to go) although I have my user ID linked to there.
The problem is, When I try to log in with my BlogSpot ID (and correct password), I end up on a 404 page; end of the line.
Could somebody please take a look? I'd prefer to get an answer here or to carl dot smotricz # gmail dot com, as I'm obviously unable to pick up answers on meta...
It seems that this gets solved by logging into Blogger in another tab (or browser window). Once this is done it seems to work.