Skip navigation



Hopefully you heard at our recent webinar (if not check back as we’ll have the recording posted soon) at CreatorCon this year we will be setting aside space called the unconference zone specially to allow attendees to setup and facilitate short ad-hoc talks about topics of their choosing.


So what is it?

If you’ve never been to an unconference or open spaces format conference before you are likely wondering what the heck I’m talking about. You may be asking yourself why would I go to a conference to hear myself talk? It’s a simple concept really, the idea is to provide time and space where participants who all share some common interest (in this case it’s ServiceNow) the opportunity to informally exchange ideas. Have you ever been to a conference only to find the topic you are most interested in absent from the agenda or wished you could have had a chance to carry on the conversation that started in a session? With an unconference format you have that opportunity. Keep reading and I’ll explain how this works.


How does it work?

At CreatorCon we will have spaces dedicated to unconference sessions. Details are still being worked out regarding exactly how many spaces we will have but expect at least two spaces that will be set aside with large whiteboards, video screens and ~15-20 chairs where sessions can be held. Near the entrance to the CreatorCon hall you will find signs directing you to where you can find information about what unconference sessions are scheduled and where they will take place. The first thing you should expect to see is a bunch of giant post-it notes on a grid on a wall or board.

Here you will be able to *propose a session* by simply writing your topic title on a giant post it and putting it on the slot on grid that indicates an open time and space. [Best Practice] Choose a topic title that will help people quickly understand what you want to talk about or continue adding a sub-title *and* include your name and email address on the post-it That’s all there is to it.


Ok, so I just proposed a session now what? By proposing a session you are expected to do a few simple things… (the plot thickens). First, if you proposed a session you are expected to show up at the time and space you chose and facilitate the conversation. You are not expected to have all the answers or be an expert on this topic, you don’t even have to stand up in front of a crowd. You should just be interested in your proposed topic, be willing to kick-off the conversation and if appropriate take notes about the conversation on the white board. That’s it.


Don’t have a topic in mind yet, that’s ok just show up. There is no need to do anything to prepare for attending the unconference zone prior to attending CreatorCon.


Why are we doing this?

A few of us (myself included) here at ServiceNow have been to unconferences before and have had very positive experiences. We want to bring this experience to CreatorCon attendees as we feel it gives attendees a great chance to make sure they can have the conversation/talk that is most important to them. No amount of planning can anticipate every topic of interest to every attendee. Sessions in the main Knowledge are designed to have broad appeal to the attendees. Here you do the opposite; go as narrow and deep as you want to. No matter how specific, it will be of interest to someone else. Want to talk about integrating ServiceNow with AWS but don’t see a scheduled session? Propose one. Want to talk about React but don’t see a session, grab a giant post-it and propose it. At an unconference the ball is in your court to have the conversation about the topic you want to talk about. Want to discuss rate limiting APIs in ServiceNow, PROPOSE A SESSION (I’ll attend).


I’m really looking forward to seeing what type of sessions occur and how the community uses this space!!


You can learn more about the unconference (aka open spaces) format at following the links and stay tuned for follow up posts that will give you tips and tricks to make the most of your time at an unconference and for more details regarding how many spaces and time slots we’ll have at our unconference zone.


- unConferencing – how to prepare to attend an unconference |

- Unconference - Wikipedia, the free encyclopedia

I wanted to point to an external blog (off the community) run by the consultants at The ServiceNow Guys. Their blog ServiceNow Pro Tips has a lot of good resources and is worth a look periodically to pick up new tips and tricks.


In particular, the posts on  What's New in Geneva Part 1 and Part 2 are insightful and deserve a read, as is this one discussing the use of GlideRecord and how it differs from the Client Side vs the Server Side.


I'll be following the blog and looking for interesting posts to highlight here. If you run across other resources that you find valuable, let me know via a comment on this post and I will add them to a daily ritual of reading the ServiceNow blogosphere.

Dave Slusher | Developer Advocate | @DaveSlusherNow | Get started at

An extremely practical and well presented email relay system, is comprised of a fast cloud SMTP server. It furthers the ability to integrate with external SMTP servers that it is suitable for most business needs. You can reduce the number of invalid emails and speed up delivery of your emails by ensuring to validate the recipients. To ensure flexibility, you can add the possibility to unsubscribe from an email notification. I will try to focus on identifying invalid email addresses. However, ensuring valid email addresses is like trying to eradicate a virus, it requires an efficient and regular intervention. Note, this is just the tip of the iceberg on outbound email performance as several other factors count as well.




Here are 6 tips reduce the number of invalid emails and speed up delivery:

  1. Educate your users and include information on the notification about how to unsubscribe.
  2. Validate that the target emails are valid.
  3. Regularly execute email verification and check the list of incorrect or undelivered emails.
  4. Prepare for emails that bounce back (e.g. out of the office, undelivered, etc.).
  5. Plan delivery of bulk emails during non-busy times.
  6. Ensure the target email servers have white-listed the relay SMTP server.


For these examples, I have set the following emails for testings:





abel.t uter@exa



Space on example



No @

aileen.mottern@ example.NOEXISTANT



NOEXISTANT is not a domain




single quotes ' at beginning and end



Email is valid


I added the recipients to an incident Assigned to and Watch list and added additional comments.

assigned watch list.jpg


1. Educate your users and allow the option to unsubscribe.

It is difficult to know the user that need to read an email notification before many implementations. For flexibility, our system allows your to enable or disable your email notification as part of the user preferences. Provide information for how your users can disable the unwanted notifications.


Valid emails addresses are the recipients that will receive and potentially read the email notification.


Target recipient

Correct syntax

Target exist

User read email


















In addition, to ensure flexibility, your email notification  can have an unsubscribe link on the notification itself or to the user notification preference settings.This will avoid users marking your emails as spam on the target email, or triggering unwanted emails back, allow the sense of agreement with the target user, etc. Less emails means less time to deliver future notifications.


e.g On your notifications, you can add a mail script to include an unsubscribe link:

template.print('<a href="' + gs.getProperty("glide.servlet.uri") + "" + email_action.sys_id + '">Unsubscribe</a><br/>\n');


Alternatively, an email script that will allow you to unsubscribe.

email script unsubscribe.jpg


2. Validate that the target emails are correct

This is one of the most important steps. Check and double check that the email syntax and a basic domain are correct. This is target to the users that have incorrectly written emails.

Ensure your email addresses lists is tuned, and the syntax is correct. Below is a sample findInvalidEmailAddresses script the checks if the email address is valid. To validate the domain, you could use the instance search queries. e.g. emails that ends with "", etc.

Invalid emails are all those emails that will never get delivered (email is incorrect) or read on by the user the email address was provided (e.g. email account is abandoned)

In our examples:

validate target email.jpg


The email system will perform a basic syntax check and will pick very few emails as follow:

>Notification 'Incident commented' (0d51edbac0a80164006963b000ff644e) excluded recipients because user's device contains an empty or invalid email address (see "cmn_notif_device.email_address"): 'Adela Cervantsz' (0a826bf037102000e0bfc8bcbe5d7a)

Any other user which email were accepted will show on the email logs as:

> Notification 'Incident commented' (0d51edbac0a80164006963b000ff644e) included recipients via notification's "Users/Groups in fields" (e.g., watchlist, assigned_to, etc): 'Alejandra Prenatt' (22826bf03710200044e0bf8bcbe5dec), 'Jonny Seymour' (b6392da30f1856146cce1050efd), 'Aileen Mottern' (71826bf03710200044ebfc8bcbe5d3b), 'Abel Tuter' (62826bf037100044e0bfc8bcbe5df1)

On the email itself the recipients will look like: aileen.mottern@example.NOEXISTANT, abel.t uter@exa,, ''

email recipients.jpg


To validate the syntax of emails stored on the sys_user table, here is a background script that can help you find the some of those emails with the incorrect syntax:


findInvalidEmailAddresses(!1); // false !1 to NOT set notification off automatically  
function findInvalidEmailAddresses(setnotifyoff) {  
    var a = [], // holds the message back  
        b = [], // holds the sys_id's for the link  
        f = "emailISNOTEMPTY^active=true^locked_out!=true^notification=2",  
        h = 10000, // max results for the query to avoid unlimited queries  
        e = setnotifyoff == !0; // check if want to set notification off on the user  
    a.push("*** Scripts findInvalidEmailAddresses ***");  
    a.push("-----Searching for invalid email addresses: ----- setting notification off: " + e + "\nsys_user query: " + f);  
    // c is the regex to validate the email is valid. Note this is a guide  
    var c = /^\b[a-z0-9!#$%&'*+\/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+(?:[A-Z]{2}|com|org|net|gov|tv|biz|info|mobi|name|aero|jobs|museum)\b$/i,  
        d = new GlideRecord("sys_user");  
    // query for relevant users.  
    d.setLimit(h); // do not query more than 10K records  
    for (d.query(),g=1;;) {  && !c.test( && (b.push(d.sys_id + ""), a.push("User #"+ g +" Found: " + d.sys_id + ' - email = "' + + '"')) && g++ &&  e && (d.notification = 1) && d.update();  
    (d.getRowCount() >= h)  && a.push("\n**** WARNING results are higher or equal than the limit "+ h +" set for the query");  
    b.length ? a.push("\n**** Found "+ b.length + " possible invalid email(s) of " + d.getRowCount() + " emails checked. Run 'findInvalidEmailAddresses(!0)' to disable them" + "\nTo list them use the following link:\n"+ gs.getProperty('glide.servlet.uri') + "" + b.join(",") ): a.push("\n**** All emails compliant: " + d.getRowCount() + " emails checked." );  
    // print the message for the background script  

For our examples, it will discover the following problematic emails:

---background script result-----

*** Script: *** Scripts findInvalidEmailAddresses ***

-----Searching for invalid email addresses: ----- setting notification off: false

sys_user query: emailISNOTEMPTY^active=true^locked_out!=true^notification=2

User #1 Found: 0a826bf03710200044e0bf10bcbe5d7a - email = ""

User #2 Found: 22826bf03710200044e0bf10bcbe5dec - email = "''"

User #3 Found: 62826bf03710200044e0bf10bcbe5df1 - email = "abel.t uter@exa"

User #4 Found: 71826bf03710200044e0bf10bcbe5d3b - email = "aileen.mottern@example.NOEXISTANT"



**** Found 4 possible invalid email(s) of 527 emails checked. Run 'findInvalidEmailAddresses(!0)' to disable them

To list them use the following link:



---background script -----

You will need to search for those users and then set the notification = Disable. After that, you may need to contact the users to correct their email addresses.


3. Regularly execute email verification and check the list of incorrect or undelivered emails

Regular expressions and email checks will not filter all invalid emails. Even if your email syntax is correct and validated by regular expressions, you do not really know whether an address is valid until you send an email to it. Even if the email arrives in the inbox, that doesn't mean it has been read.


Invalid emails could cause delays to the overall email delivery.

  • Invalid email could cause SMTP retries event if only ONE email of 100 on the recipient list does not exit.
  • Bounced emails can execute inbound actions and potentially create email loops that cause some email outage, than bounce back, then again.
  • Extra processing for the irrelevant emails could be relevant.
  • Target email systems could black-list the SMTP relay, delaying the delivery even further.


To avoid those problems, there are several email validations that can be performed. The automatic validation is not available on ServiceNow yet: if you have an external email provider that can test the target emails, you can provide them with your email list and they will validate if they exist on the final exchange or not. They will extract the MX records from the email address and connect to mail server (over SMTP and also simulates sending a message) to make sure the mailbox really exist for that user/address.  If you do not have those services, you can still review the bounced emails on your instance to manually validate those emails. For those emails that bounced back, set the notification = disable on the sys_user form to avoid further unwanted emails. Then, contact the user owners for the correct addresses.


Even then, you will need to regularly check for incoming bounced back emails as users leave companies, email changes, etc. There are several other cases some where email will not get delivered. e.g. Emails bounced back because the target email has full mailboxes could indicates that no ones read that mailbox.


This is important as your instance will retry to send on certain cases, even if it is an invalid email depending on the SMTP response.


You will need to search your skipped emails regularly to fix the problematic emails manually. To avoid them, set the notification - disable on the related sys_user record.


This is an example email:

>Subject:Undelivered Mail Returned to Sender

>From:MAILER-DAEMON (Mail Delivery System)


State: Ignored

Mailbox: Junk


Body = [ This is the mail system at host I'm sorry to have

to inform you that your message could not be delivered to one or more recipients.

It's attached below. For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can delete your own text

from the attached returned message. The mail system <aileen.mottern@example.NOEXISTANT>:

Host or domain name not found. Name service error for name=example.NOEXISTANT type=A: Host not found

You will need to search for email aileen.mottern@example.NOEXISTANT, and set the notification = Disabled for the associated user.


4. Be prepared for emails bounced back (e.g. out of the office, undelivered, etc)

Each email you send is potentially one email back to be received. Be prepared. To ignore emails, you either configure your email filters on the email configuration or install the "Email Filters" plugin. If using email configuration, ensure the properties to ignore unwanted emails are set to cover all your bounced email cases.


For example: glide.pop3.ignore_headers, glide.pop3.ignore_subjects, glide.pop3.ignore_senders


For most sophisticated filters, use the "Email Filters" plugin. Email filters take over the email configuration filter. Once enabled, administrators can configure specific email filtering preferences by using a condition builder or a condition script.

With Email filters enabled, glide.pop3.ignore_headers, glide.pop3.ignore_subjects and glide.pop3.ignore_senders  will get ignored.

See Email Spam Scoring and Filtering (will need to login to HI to view) to know how to use the Email Filters plugin to filter emails which have been scored as spam, when using the ServiceNow email infrastructure.


If your email does  meet the filters/Email filters conditions, you will receive a message "ignored by filter" on the logs, an the email will get skipped.

* Information    - Skipping 'Create Incident', ignored by filter

If your email filters are NOT configured correctly, the bounced emails will execute your inbound actions

5. Plan delivery of bulk emails on non-busy times

Emails sent by bulk may delay critical business emails. Many of those emails will get rejected by the target SMTP server and resend once again. Validate with your administrator the best times to send bulk emails. If it's the first time you will send a bulk, ensure you monitor the bounce-back emails to disable the notification on the related users for those problematic email addresses.


You can also trigger some notification at an specific time using our gs.eventQueueScheduled(event, record, parm1, param2, date-time) function that could trigger your notification at the required date-time. For example: gs.eventQueueScheduled("incident.reminder", current, gs.getUserID(), gs.getUserName(), current.u_reminder);


Keep in mind, there are five (5) email properties will potentially add a relevant delay on email delivery because of invalid emails causing defer retries:

glide.smtp.default_retry, glide.smtp.defer_retry_ids, glide.smtp.fail_message_ids, and

Please set the properties to to meet your business requirements. The emails will be queued and re-queued several times for the problematic email addresses.


#1 glide.smtp.default_retry: Enables (true) or disables (false) resending email when an unknown SMTP error code is encountered.

The instance only recognizes the SMTP error codes defined in the glide.smtp.defer_retry_ids property. Default value: true


#2 glide.smtp.defer_retry_ids: Specifies the comma-separated list of SMTP error codes that force the instance to resend email.

Default value: 421,450,451,452

421 -    <domain> Service not available, closing transmission channel-

450 -    Requested mail action not taken: mailbox unavailable- e.g. SMTP server could not access a mailbox to deliver your message

451 -    Requested action aborted: local error in processing- e.g. This error is usually SMTP relaying service from too many messages.

452 -    Requested action not taken: insufficient system storage-


#3 glide.smtp.fail_message_ids: Specifies the comma-separated list of SMTP error codes that prevent the instance from resending email.

Default value: 500,501,502,503,504,550,551,552,553,554


500 -     Syntax error, command unrecognised - e.g. Your antivirus/firewall interfering with incoming and/or outgoing SMTP communications

501 -     Syntax error in parameters or arguments - e.g. Invalid email addresses or an invalid domain name recipient. Error can indicate bad connection

502 -     Command not implemented

503 -     Bad sequence of commands - e.g. Error, particularly if repeated, indicates bad connection. Verify authentication settings

504 -     Command parameter not implemented

551 -     User not local; please try <forward path>

552 -     Requested mail action aborted: exceeded storage allocation - e.g. The recipient’s mailbox has reached its maximum allowed size.

553 -     Requested action not taken: mailbox name not allowed - e.g. Invalid email address.

554 -     Transaction failed - e.g. when its anti-spam firewall does not like the sender’s email address, or the sender’s IP address, or the sender’s ISP server


#4 Specifies the maximum number of recipients the instance can list in the To: line for a single email notification. Notifications that would exceed this limit instead create duplicate email notifications addressed to a subset of the recipient list. Each email notification has the same maximum number of recipients. Default value: 100. This is ONLY valid for recipients created by the email notification system (it does not include emails added by scripts or email client).


On each duplicated email, email logs will show:

InformationEmail with 4 recipients is split into 4 separate emails because property (Email 4 of 4)


On our example, the final emails look as follow:

email properties.jpg


#5 Specifies how many emails to send through each new SMTP connection. The instance establishes a new SMTP connection if there are more emails to send than the specified value. Default value: 100


#4 and #5 can be used to set email throttling. e.g 100 email with 50 recipients max each vs 100 emails with 1 recipient max each. It completely depend on your target emails and email capacity of the target exchanges.


In a nutshell, plan your email delivery, set the resend properties accordingly with a reasonable to email throttling to protect system performance.


6. Ensure the target email servers have white-listed the relay SMTP server.

If your SMTP server is not white-listed, spam system could penalize it by adding transaction time to the relay or delaying delivery. This is VERY common. If the number of emails bounced back or the delivery time increases after bulk emails, check the target email address SMTP servers have white-listed the relay SMTP server on your instance. If you are using our SMTP relay system, ServiceNow highly recommends that you configure your target mail exchange systems to retrieve our Sender Policy Framework (SPF) records dynamically, to white-list our Email servers. See Allowing email delivery from ServiceNow to your mail servers for more information.






A final word. Less is better. Less email recipients means you spend less, you need less storage on the target, you need a smaller processes and

you sent them faster. To make it less, you need to regularly validate your target emails even if it means donkey work. If you do not check regularly, as more invalid emails populate your system, the more time your email will take to get delivered.


Hope it helps. I have performed the tests on Geneva, using Chrome as browser.


Additional information can be found here:

Confused about how to use OAuth 2.0 to authenticate to ServiceNow REST APIs? Check out this new video tutorial the walks through setting up OAuth 2.0 and making requests to ServiceNow REST APIs using OAuth 2.0.



Topics Covered:

About OAuth

Comparison of basic authentication and OAuth requests

Setting Up OAuth on a ServiceNow instance

Requesting tokens

Using tokens to make REST API requests

Requesting a new access token

Issuing requests from a terminal using curl


ServiceNow product documentation:

Enable OAuth with inbound REST

Set up OAuth

Use a third-party OAuth provider

OAuth tokens

OAuth API request parameters


The Knowledge Base is kept current with frequent edits and additions. Find out what is new and stay up-to-date on the latest ServiceNow Knowledge Base articles by reviewing the weekly KB digest.


Recently added and updated articles on User Interface:




User Interface (UI)

I'm excited to announce that we've released new REST API documentation on the ServiceNow Developer Portal. You can find the new docs by selecting API from the top menu and then choosing REST. Here you'll find developer focused documentation on ServiceNow Platform REST APIs including detailed documentation on the resources, parameters, status codes, authentication along with code samples in curl and python for making requests and sample responses.


ServiceNow Developer REST API Documentation



Today we have coverage of the REST APIs available in the Fuji and Geneva release (note you can select the release specific docs in the bottom right hand corner) including the Table, Import Set, Aggregate, and Attachment API (Geneva only). We will add coverage of additional REST APIs that are available soon.


Hope you enjoy and please let us know any feedback you have positive or negative so we can make these docs better over time!




Monitoring and identifying the time in which your team handles an incident, problem, or record is important to understand the circumstances and logic of activity. By default, the activity formatter is enabled on the Task [task] table and tables extended off the Task table, such as the Incident [incident] table. Starting in Geneva and UI16, the activity formatter shows updates in real time so you can see the latest information without refreshing the form. User presence enables you to see when other users are entering comments.


For users on select Fuji releases, you may notice that your activity log no longer shows the date and time in which the activity happened. You will notice the missing activity entries if you try to expand the activity details or if you attempt to open it in a new tab. This can lead to confusion among your team as they are not sure how long it has been in between responses and activity on a record. Here's the kicker, if you reload the form, make an update to the record, or expand and refresh, the activity date and time stamps come back. This leads users to think that the missing activity entries were just a fluke, only to experience it again later down the road.

Activity expanded missing date time stamp (2).jpg

Note:  the activities are no longer just collapsed but entirely hidden and shouldn't be.


Good news is that if you are upgrading to Fuji Patch 7 Hot fix 6, Fuji Patch 8, or Geneva, your activity entries are retrieved (or preserved depending on what release you are coming from).


There are two ways to resolve this issue and retrieve your activity time stamps:

  • Upgrade
  • Create an onLoad global Client Script


If it is on your roadmap, you can skip the workaround and have this problem resolved in Fuji Patch 7 Hot fix 6, Fuji Patch 8, and Geneva. But, if upgrading is not an option for you at this time, you can use the following onLoad global Client Script to reload the missing headers after they are hidden. The client script must be wrapped within "addLateLoadEvent" to execute after the rest of the base system scripts.

function onLoad() {
  addLateLoadEvent(function() {


For more information on this Known Error in Fuji, see After reloading or saving a record, the Activity Filter does not render Activity entries (such as the date/time stamp) when expanding. A few other users experienced this issue back in September. To join that conversation on how others resolved this issue, see Re: Activity now showing time.

There are a few cases where the browser acts as password manager software. It will store your passwords to safely save you time and efforts. Where it sounds like a good plan, there are times when you get an unexpected memo from the headache department. Sometimes Chrome, Firefox and IE will set autocomplete for your password to "on" as a result of passwords being saved for specific instances. We clearly set HTML on the password fields to say "do not auto-complete" but can be ignored.


In Chrome auto-complete for passwords is ON by default. To double check, just open your Chrome settings then go to advanced, and select “auto-complete passwords” ON. After that, to access your settings, go to: chrome://settings/passwords to manage your passwords in Chrome.




If everything works fine, when you login into the instance the first time, Chrome will allow you to save the password.

remember password chrome.jpg


To see all of your passwords saved on Chrome, navigate to chrome://settings/passwords

see all passwords.jpg

This works fine and the next time you try to login, it will auto-complete the password. You can recognize it because the background of the field usually changes to yellow to indicate that autocomplete is working.

autocomplete success.jpg

When everything goes smoothly, you can efficiently login to your instance and save yourself the hassle of having to remember your password with auto-complete.


When the browser password management changes go wrong

I worship the ground Chrome walks. As painful for me as it is, there are some cases when the password fields are auto-completed even when it should not be. On Chrome, the browser matches the password with the "previous" field (not necessarily the login name). On ServiceNow, password fields could be anywhere in the form and even when the autocomplete="off" is set on them, some browser just ignore them.


Example #1: The User form (sys_user)

If you open our sys_user form, change the password and click "update" (similar to form submit), the browser will try to save the password and associate it to the previous field.

password associated.jpg

In this case, it will associate the password value with the 'Department' field.

password department field.jpg

If you open any other user from the same department, the autocomplete will incorrectly auto-complete the password. Saving the record will override the password. It will even ask you to save when leaving the form even if you have not changed anything.

save password.jpg

To avoid this problem of having the password associated with the wrong user, move the password field below an unique field like User ID or disable auto-complete.

disable auto complete.jpg


Example #2: The X.590 form

Another form with a similar problem is X.509 Certificate (sys_certificate). If auto-complete is enabled and have records, it will set the key store password that can cause problems on some integrations.

x.590 form.jpg

You can move the password field below an fairly unique field like Name or disable auto-complete to avoid the it from setting the key store password.

key store password.jpg


Example #3: SOAP message form

On the SOAP message (sys_soap_message), the basic authentication fields get auto-completed. These fields can be overwritten when saving the form by the values auto-completed. The problem here is that both fields are initially empty.

soap message.jpg


Luckily, the auto-complete password problem will only affect forms with password fields. The complexity of the problem is that it could happen when users are UNAWARE of the auto-complete. Also, the password is saved to the whole domain ( sometimes) so it will cross into different instances or forms (e.g. passwords set on the sys_user form, then recalled by the browser on sys_soap_message (as showed on example #3). Note that most sophisticated password managers like Lastpass, Keepass, 1password, etc do not have the same problem as IE, Firefox and Chrome have. Also, Opera and Safari seems to work fine as well.


Here are the list of forms that can be affected by the browser password auto-complete:




Column name




































































In a nutshell, if you are using auto-complete password on your browser, you need to be extra cautious. If the password fields are NOT next to a non-empty or unique field to allow the password managers to link to the correct value, then it's safer to disable the auto-complete function for good. If you see YELLOW background, then you are in trouble. I personally use most sofisticated password managers like Lastpass, 1password or Keepass.


I have tested this using Chrome 48.0.2564.116 as browser and on Fuji release.


More information here:

Filter Blog

By date: By tag: