I have a google doc that has a script in it. It basically allows for more succinct posting to a site, but that's not the problem. I made a copy of the script, and now it's saying that it needs permission to use it, something that it's never done before. I tried to approve it, but it keeps immediately going to a "something went wrong" page the very second I click "agree".
In short; I try to run the script, it says that I need permission (from myself) to use it. It opens a new window telling me to select an account, I select my account, and then gives me a choice to select whether I give the script permission to run. Then, when I click accept, it immediately goes to an error page.
I've tried reloading the page, signing out of google, rebooting, even using a different account, and I've clicked it like, fifteen times now, and it takes me to the same error page every time. Does anyone know what's going on?
Here's an example.
https://youtu.be/7RsSv5otVkM
Related
I'm working on a project in which users automatically gain points if it's been more than 24h since their last login and a friendly message appears on the screen telling them that. If they log in again, nothing happens. But for me, as the dev of the project, I get a lot of scary red error messages in the browser logs showing me that a forbidden action has been tried, because when the backend detects that already made the transaction, it returns a 403, and this happens every time someone logs in or close and reopens the site.
I'm a bit confused whether this should really be the treatment for the case and wondering about how messed up error statistics of the site could get because of things like this, where nobody actually tried to perform a forbidden action, just the scheduled predictable behavior of the platform.
Should I change it to a 2xx status code?
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.
If I make an edit to a Trac ticket, but someone beat me to it, this message is displayed:
Ideally, I would read this message and figure out what I can overwrite and what I should not. But, depending on this message to keep users from overwriting what was submitted is not something that we should depend on:
This may sound a little harsh, but you'll see, when you do usability tests, that there are quite a few users who simply do not read words that you put on the screen. If you pop up an error box of any sort, they simply will not read it.
Is there a better way to prevent these overwrites in Trac - e.g., if a ticket has been modified while you were modifying it, you must refresh the page, etc?
Yes, if the server would send the page modified outside and if the javascript running in your browser could merge that into your local changes. But noone has implemented it in the current trac.
DUPLICATE POST
I have an app where users can see pictures of other users who are using my app and like it when they want to. The problem is that many People are telling me that they can't like pictures even when they just downloaded my app for the first time and want to like something.
The error is:
Error message: {"meta":{"error_type":"APINotAllowedError","code":400,"error_message":"you cannot like this media"}}
For example a picture gets 20 likes without a problem and after that it produces the error mentioned above when another user wants to like it. After some time (maybe a day) it works again for a few likes until the error comes back. My app is whitelisted but why this error happens?
The amount of likes before this error starts is different from user to user. It can also be that a pic from a completely new user of my app gets this error within the first like. Is it because the pic already had many likes before? Is Instagram using advanced imits for API-likes?
I have few simple Xpages, where i test and learn the newest features in Domino 8.5.3.
Now, after some latest changes somehow i'm not able to delete Documents. The Application asks me for the User Name and password, which i enter and which are correct. However, nothing happens (well, the system thinks few seconds over) and i'm asked for my credentials again... and again.. If i press "cancel" -> i got the expected result -> error 401.
The strange thing as well, if even i give for the "anonymous" the editor rights with the "delete documents" checked, i'm still asked for the credentials...
Well, i think I need now some ideas and tips where can i look after in order to solve the "undeletable documents" problem.
The "Delete" button is made using the Simple Action "Delete Selected Documents".
Update: After looking into the logs (thanks Simon O'Doherty for the hint below!) i found out the following message
28.02.12 19:20: Exception Thrown
com.ibm.xsp.acl.NoAccessSignal: NotesException: Notes error: Document locking is enabled. You must lock the document before deleting.
After removing the setting "Allow Document locking" everything works fine.
The next question, however, and it seems to be intresting, if i want to use this setting - how to make the standart actions (it looks like at least "Delete Selected Documents" has some problems) work properly ?
Or do i have to use SSJS only ?
In the ACL settings. Click Advanced tab. Check that "Maximum Internet name and password access" is at least a level that allows you to edit documents.
May need to restart your browser for that to be registered.
If it is still an issue at that point then the following Debug may give more hints.
Check the XPages logs in the IBM_TECHNICAL_SUPPORT folder of the server.
Check the elements on the page are not being pulled from another location that would require access.
Check for Authors/Readers fields.
The following debug on the server will allow you to see when an ACL call is made, what is asked for and what it got.
Warning This is very verbose debug, so it should only be activated for the test. Also do not paste the results anywhere externally without first sanitizing. (as it would be confidential to you).
DEBUG_THREADID=1
DEBUG_SERVER_ACL=2
I have also seen this behaviour in our application.
The issue is caused by the "Allow document locking" option.
Either you do not need this feature; then just uncheck in the application properties. If you intend to use the feature, you have to lock the document in your code prior to deleting it.
Add a execute script simple action before delete simple action and write the following code
var doc:NotesDocument = currentDocument.getDocument();
doc.lock();
or
dataSource.getDocument().lock();
It might be as easy as:
- check your ACL. Do you have delete rights? Default is off