RE: Storing passwords in records/Authenticating IOC with other servers

[Freddie Akeroyd - STFC UKRI via Tech-talk <tech-talk at aps.anl.gov>]

Hi Gary,

 

That’s a good point, and I think the answer is “maybe” – I tested just with a softioc and the monitor is triggered, but by the time the CA thread runs to publish the result the Db value has gone back to “” . I wasn’t trying this with an actual asyn call in MY_RECORD, so that may cause a delay and it to behave differently.

 

Regards,

 

Freddie

 

C:\Instrument\Apps\EPICS>camonitor MY_RECORD

MY_RECORD                      <undefined>  UDF INVALID

MY_RECORD                      2024-07-19 17:29:00.268839

MY_RECORD                      2024-07-19 17:29:16.902356

 

From: Yendell, Gary (DLSLtd,RAL,LSCI) <gary.yendell at diamond.ac.uk>
Sent: Friday, July 19, 2024 5:17 PM
To: 'Marco Filho' <marco.filho at ess.eu>; tech-talk at aps.anl.gov; Akeroyd, Freddie (STFC,RAL,ISIS) <freddie.akeroyd at stfc.ac.uk>
Subject: Re: Storing passwords in records/Authenticating IOC with other servers

 

Hi,

 

Wouldn't a camonitor show MY_RECORD change to the password and back again with this?

 

Cheers,

Gary

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Freddie Akeroyd - STFC UKRI via Tech-talk <tech-talk at aps.anl.gov>
Sent: 19 July 2024 16:23
To: 'Marco Filho' <marco.filho at ess.eu>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: RE: Storing passwords in records/Authenticating IOC with other servers

 

CAUTION: This email is from outside of the organisation and has a suspicious subject or content. This might likely be a phishing email. Do not click links or open attachments unless you recognise the sender and know the content is safe. If in doubt, contact IT Helpdesk.

 

Hi, does something like

 

record(stringout, "MY_RECORD")

{

    field(DTYP, "asynOctetWrite")

    field(OUT, "@asyn( … )")

    field(FLNK, "MY_RECORD_RESET")

}

 

record(stringout, "MY_RECORD_RESET")

{

    field(VAL, "")

    field(OUT, "MY_RECORD NPP")

}

 

Work? The linked “MY_RECORD NPP” should clear the initial record value without processing it again (so not sending a blank password to asyn)

 

Regards,

 

Freddie

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Marco Filho via Tech-talk
Sent: Friday, July 19, 2024 3:55 PM
To: tech-talk at aps.anl.gov
Subject: Storing passwords in records/Authenticating IOC with other servers

 

Hi, all

I am creating an epics ADDriver that needs to communicate and authenticate with another server. The authentication requires a password and a username.
Since I want everything to be as dynamic as possible, I wanted to create a record to use the password to authenticate, but I don't feel comfortable only protecting the record with ASG because it feels like a thin layer of protection.

I tried making an asynOctetWrite record that passes a value to MYDriver::writeOctet() without storing the value passed. In other words: something that would behave like:

caput MY_RECORD PASS
(Function MYDriver::writeOctet gets called with PASS passed as an argument to the function)
caget MY_RECORD
MY_RECORD                          #Shows nothing, nothing is actually stored in the record.

But I could not succeed in making this record only with asyn. The best solution I can think of now is reading the password from a file which again doesn't seem like the optimal solution.

This is probably not a too specific problem, so I'm wondering if there is already any elegant solution for that? Can anyone think of a better approach? Or maybe an already-existing record that does something similar?

Thanks for any suggestions,

Marco

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom.