Thanks Mike,

It seems to not be working due to something in the way things are being
saved/display.  If I manually set the Account Restrictions in the UI to a
date, it decrements that date on the UI each time it is saved.
Additionally, the date shown in the UI does not match the date we are
seeing in the database.



For example, I set the date here to 10/1/2019 and saved.  You can see it
moved it back to 9/30.



[image: Screen Shot 2019-09-30 at 10.47.57.png]



Yet in the database it does show 10/1:



In database:

access_window_start: 09:00:00

  access_window_end: 07:00:00

         valid_from: 2019-10-01

        valid_until: 2019-10-01

           timezone: America/Los_Angeles

          full_name: NULL

      email_address: NULL

       organization: NULL

organizational_role: NULL

         session_id: NULL

          entity_id: 65







Now I will save it again, making no changes on the UI. Once again
decrements one day, now showing 9/29:


[image: Screen Shot 2019-09-30 at 10.49.35.png]



And in the database shows 9/30



access_window_start: 09:00:00

  access_window_end: 07:00:00

         valid_from: 2019-09-30

        valid_until: 2019-09-30

           timezone: America/Los_Angeles

          full_name: NULL

      email_address: NULL

       organization: NULL

organizational_role: NULL

         session_id: NULL

          entity_id: 65





Functionally, when the database is set to a window that matches current
date/time, the user can login as expected.



Any ideas?


Regards,

-Steve

(415) 320-1102 <https://www.google.com/voice/#phones>


On Mon, Sep 30, 2019 at 8:20 AM Mike Jumper <[email protected]> wrote:

> No, nothing has changed in the URL format, nor in the way parameters in
> the URL are handled.
>
> - Mike
>
> On Mon, Sep 30, 2019, 08:14 Steven Pollock <[email protected]> wrote:
>
>> Attempting to move from 0.9.13 to 1.0.0, using mysql for auth.
>>
>> We have been using the auto login format "
>> http://10.80.100.199:8080/guacamole/#/client/NABjAG15c3Fs/?username=user3&password=pword";
>> where connection id, type and source are base64 encoded.
>>
>> This no longer seems to be working so we are wondering if something has
>> changed with the format of the URL?
>>
>> Regards,
>>
>> -Steve
>>
>> (415) 320-1102 <https://www.google.com/voice/#phones>
>>
>

Reply via email to