Skip to content

state machine impl #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 14 commits into from
Nov 20, 2020
Merged

state machine impl #8

merged 14 commits into from
Nov 20, 2020

Conversation

pfitzseb
Copy link
Member

and first iteration of a server

and first iteration of a server
@aviks
Copy link
Member

aviks commented Nov 11, 2020

Looks like a great improvement in clarity on first glance. Might be useful to document the state machine in a diagram.

@pfitzseb
Copy link
Member Author

That's the plan. I was kinda hoping to automate that though :)

@StefanKarpinski
Copy link
Member

Would also be great to put type annotations on various fields where possible.

@pfitzseb
Copy link
Member Author

This now has a few (integration) tests via a mock server and properly typed structs.

State machine:

@pfitzseb pfitzseb marked this pull request as ready for review November 13, 2020 09:46
@pfitzseb
Copy link
Member Author

There's also the question whether we care about Julia versions older than 1.3 here. I can just switch to Downloads.jl if not.

@StefanKarpinski StefanKarpinski self-assigned this Nov 17, 2020
@bmharsha
Copy link
Member

We are encountering following error https://gist.github.com/bmharsha/590067fb52899d520146bd8ea3e08001#file-error1-md when we tried using PkgAuthentication.jl from this PR. Pkg server was set to pkg.juliahub.com when we encountered this error. This server requires end-users to be authenticated inorder to download packages.

@StefanKarpinski
Copy link
Member

I made some tweaks to this and asked some questions in a PR to this PR: #9. Let's address the questions (marked with "QUESTION") and then we can figure out whether to merge my changes or not. I'm especially interested in the expiration logic. Is the key ever expiry rather than expires or expires_at or expires_in? If both expires_at and expires_in are set, I think the best thing to do is to take the minimum of expires_at and the locally computed expiration time based on the current time and expires_in. Ideally the server should be sending both expires_at and expires_in. The reason for this is so that if there's significant clock skew between the client and the server the worst case that can happen is that the client just refreshes their token every time, which is slow but works. Otherwise if there's clock skew the client could end up refreshing too infrequently, leading to auth failures.

@pfitzseb
Copy link
Member Author

Left a review over at #9 that should address your questions.

Adding another toml["expires_in"] + mtime > time() check totally makes sense, yes.

@pfitzseb
Copy link
Member Author

Alright, pushed a commit that addressed your concerns and improved the expires_in/expires_at situation.

Copy link
Member

@StefanKarpinski StefanKarpinski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great to me aside from the one question about @debug versus @warn.

@pfitzseb pfitzseb merged commit 4732725 into master Nov 20, 2020
@pfitzseb pfitzseb deleted the sp/statemachine branch November 20, 2020 21:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants