That was a nice testcase for one of my scripts. I was just testing something at 2022-01-26T15:02:16 localtime (14:02:16 UTC) - and it worked - when suddenly an unexpected message from the script appeared at 2022-01-26T15:04:03:

Use of uninitialized value in printf at -e line 12, <> line 158.

Strange, also my device didn't have a name in the output of my script anymore.
Another run of my script revealed that it was taking a long time to request a cookie.

After finding out that the website was a bit down and much more testing I found the problem in my script: it didn't take the case of invalid cookies into account, where the input is unusable. No JSON, but HTML instead. That's what you get, a webpage with this message in HTML:

   World Community Grid's website is undergoing planned maintenance, but
   we'll be back up shortly. Please visit us on Facebook or Twitter for more
   information.

Since that isn't JSON, my script's only output were complaints about uninitialized values. That's not very helpful, so I modified the program to test if anything that looked like JSON could be found first, before outputting valid records. That was not much, but just a tiny little bit more helpful.

(For those who are interested , wcgstats is the script that is involved. )

Thanks for the interest, BobbyB!

There are many ways indeed.
One way would be to write a small script that substitutes your personal credentials in-place in the designated file. E.g.,

#!/bin/sh
perl -i -wpe '
    s/^(MAILADDR)="your_e-mail_address"/$1="joe\@example.com"/;
    s/^(PASSWORD)="0[^"]*0"/$1="MY_SECRET_PASSWORD_FOR_WCG"/;
    s/^(MEMBER)="youraccountname"/$1="YOUR_REAL_MEMBERNAME"/;
    s/^(VERIFY)="x[^"]*x"/$1="YOUR_VERIFICATION_CODE"/;
' "$@"

Here, fill out the real credentials and save this code to wcgcreds.sh or so and then chmod 700 your credentials script.
Don't forget the backslash before the @ in your real e-mail address.
Also, if your password contains a slash, change the current slashes in the PASSWORD line into something like a comma (if your password doesn't contain a comma), like this:

s,^(PASSWORD)="0[^"]*0",$1="MY_SECRET_PASSWORD_FOR_WCG",; # 3 commas instead of 3 slashes

If your password contains an apostrophe, like e.g. "it's a secret", change each apostrophe into apostrophe backslash apostrophe apostrophe, like this:

s/^(PASSWORD)="0[^"]*0"/$1="it'\''s a secret"/; # using "'\''" to escape the apostrophe in my password

This script would work on wcgstats as well as on wcgresults, since each pair of credentials (MAILADDR/PASSWORD vs MEMBER/VERIFY) is unique in the scripts.

Don't forget to update this small credentials script if anything changes in your credentials.

EDIT- Come to think of it, if your password contains any non-alphanumeric character, place a backslash in front of each non-alphanumeric character (except the apostrophe), then apply the apostrophe substitution (using "'\''" to escape any apostrophe in your password). There are many non-alphanumeric characters with special meaning in Perl.

EDIT 2- Because it just works like that, even more fun if your password contains a quotation mark. In that case, and your password is stored in a string surrounded by quotation marks itself, you must use backslash backslash in front of the quotation mark to escape the quotation mark. E.g., if your password is the three words "my "secret" access" (where only the word "secret" is surrounded by quotation marks), then you could use:

s/^(PASSWORD)="0[^"]*0"/$1="my \\"secret\\" access"/;

Something like:

MEMBER="jumpinjackflash"
VERIFY="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
MEMBER1="anotheraccount"
VERIFY1="11111111111111111111111111111111"

source wcgcreds

Seems I'm on the wrong script. more this one. I'm sure you know what I meant. Both together in wcgcreds

MAILADDR="jumpinjackflash@example.com
PASSWORD="Itsagasgasgas"
MAILADDR_1="another_e-mail_address"
PASSWORD_1="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
MAILADDR_2="yet_another_e-mail_address"
PASSWORD_2="BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"

a) I disagree strongly.
a) 1) KISS -> Or "Keep It Stupidly Simple" so as to not offend.
b) You are the author and if you decide the file is named wcgcredentials (or whatever) then so it is. The place is the home directory of the user. There must be an environment variable available to the script which points to the home directory. Then if the scripts are put on the path somewhere it will still point to the logged in user home.
c) Then that should be in an external file. Why not the same one? If they are smart enough to fiddle with your script then they are smart enough to adapt to an external config file.
d) Did not get that far into the options TL;DR

In any case it's your stuff and so be it. This was just a thought (of how I would do something like that).