-
Notifications
You must be signed in to change notification settings - Fork 43
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
Adapt the users service to the HTTP/JSON API #1117
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation-wise, it looks good. However, I am not convinced with the API design. But I am not a big fan of users D-Bus API, so it is probably just a consequence.
/// It emits the Event::RootPasswordChange, Event::RootSSHKeyChanged and Event::FirstUserChanged events. | ||
/// | ||
/// * `connection`: D-Bus connection to listen for events. | ||
pub async fn users_streams( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency, we should do the same with other _stream
functions. Perhaps we should have a list of small things to fix after the big merge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeap, it would be consistent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw as all our streams return this quite complex result I think it makes sense to create type in crate::web for easier sharing.
rust/agama-server/src/users/web.rs
Outdated
let router = Router::new() | ||
.route("/config", get(get_info)) | ||
.route("/user", put(set_first_user).delete(remove_first_user)) | ||
.route( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that having a single /root
resource would be more straightforward (and extensible). Let's say that, tomorrow, we want to add another attribute.
We could have the following routes (just an idea):
- GET
/root
to get the full user. - PUT (or PATCH)
/root
to update any of the attributes (just specify the one that changes). - DELETE
/root/password
to delete the password. - DELETE
/root/sshkey
to delete the SSH key.
Alternatively, we could use PUT
to replace the whole resource and PATCH
to update only one of the elements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeap, that is something I mention when I speak about need to have some guide to have consistent API. Both ways is possible. When talking about single resource I even think about having /users/config
and methods get and patch. ( put is problematic as root password get is boolean, but patch needs value and encryption ).
rust/agama-server/src/users/web.rs
Outdated
(status = 200, description = "Configuration for users including root and the first user", body = UsersInfo), | ||
(status = 400, description = "The D-Bus service could not perform the action"), | ||
))] | ||
async fn get_info(State(state): State<UsersState<'_>>) -> Result<Json<UsersInfo>, Error> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is where the API looks confusing to me. If I need to update the user, I do call PUT
on the /users/user
route. But, if I want to get the current user, I need to get the info from /users/config
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeap, that is why I mention that we can have that /users/config
and patch when need to change it. Question is how much it will be consistent with other APIs we have.
The first location to check when something does not work is browser console which can give | ||
some hints. The second location to check for errors or warnings is output of `npm run server` | ||
where some issues when communicating with backend can be seen. And last but on least is | ||
journal on backend machine where is logged backend activity `journalctl -b`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for documenting this. I would add: busctl monitor --address /run/agama/bus
as another source of information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, I think that this busctl monitor and other useful tools for dbus observing belongs more to backend documentation. Either service or rust dir. Here I try to focus mostly on debugging issues with web UI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, sure, but given that you mentioned journalctl
too, I think it might be useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, I mention journalctl mainly because you see there if request from web UI lands to backend. If it is correctly send there, then I would continue with backend debugging. But maybe we can link backend debugging document from this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I would avoid having different documents about debugging. All the information about that matter should be in a single place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, so lets add it.
* @param {string} url - Endpoint URL (e.g., "/l10n/config"). | ||
* @return {Promise<object>} Server response. | ||
*/ | ||
async delete(url) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Co-authored-by: Imobach González Sosa <igonzalezsosa@suse.com>
@imobachgs regarding API I think it would be useful to have call tomorrow. I check current http API we have to see if it is consistent or not. So far it looks quite good and consistent ( sadly users has some specific methods especially for that root password which makes get/put with different data which looks bad ).
|
Just do document result of call:
and events:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general it looks good. Just a question: are UsersSection
and UsersPage
tests working again?
The first location to check when something does not work is browser console which can give | ||
some hints. The second location to check for errors or warnings is output of `npm run server` | ||
where some issues when communicating with backend can be seen. And last but on least is | ||
journal on backend machine where is logged backend activity `journalctl -b`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I would avoid having different documents about debugging. All the information about that matter should be in a single place.
method: "DELETE", | ||
}); | ||
|
||
return response; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure whether we should return the at all. At some point we could wrap the standard responses objects with our own information.
In any case, if we want to, we should do that in all methods to be consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, response is important if we want to check if call succeed or failed ( method ok
on response or if response is added as it is optional for non-get calls). What I do not like even on current get
is that it returns true/false
if response is not json, which is quite bad API. So providing whole response object is more clear for me.
if (changes.RootPasswordSet) { | ||
return this.client.ws.onEvent((event) => { | ||
if (event.type === "RootChanged") { | ||
const res = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What res
means?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, I use it as result of data in event. Maybe I should use to something like changed_data
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or just "changes"
Co-authored-by: Imobach González Sosa <igonzalezsosa@suse.com>
Good question about tests. It is not enabled, so lets do it and do proper mocking in it |
After a few months of work, it is time to merge the `architecture_2024` branch into `master`. It is still a work-in-progress, but all the efforts should be go now against that branch. ## Pull requests * #1061 * #1064 * #1073 * #1074 * #1080 * #1089 * #1091 * #1092 * #1094 * #1095 * #1099 * #1100 * #1102 * #1103 * #1112 * #1114 * #1116 * #1117 * #1119 * #1120 * #1123 * #1126 * #1129 * #1130 * #1131 * #1132 * #1133 * #1134 * #1136 * #1139 * #1140 * #1143 * #1146 ## Other commits * 8efa41f * 9e2dec0
Prepare for releasing Agama 8. It includes the following pull requests: * #884 * #886 * #914 * #918 * #956 * #957 * #958 * #959 * #960 * #961 * #962 * #963 * #964 * #965 * #966 * #969 * #970 * #976 * #977 * #978 * #979 * #980 * #981 * #983 * #984 * #985 * #986 * #988 * #991 * #992 * #995 * #996 * #997 * #999 * #1003 * #1004 * #1006 * #1007 * #1008 * #1009 * #1010 * #1011 * #1012 * #1014 * #1015 * #1016 * #1017 * #1020 * #1022 * #1023 * #1024 * #1025 * #1027 * #1028 * #1029 * #1030 * #1031 * #1032 * #1033 * #1034 * #1035 * #1036 * #1038 * #1039 * #1041 * #1042 * #1043 * #1045 * #1046 * #1047 * #1048 * #1052 * #1054 * #1056 * #1057 * #1060 * #1061 * #1062 * #1063 * #1064 * #1066 * #1067 * #1068 * #1069 * #1071 * #1072 * #1073 * #1074 * #1075 * #1079 * #1080 * #1081 * #1082 * #1085 * #1086 * #1087 * #1088 * #1089 * #1090 * #1091 * #1092 * #1093 * #1094 * #1095 * #1096 * #1097 * #1098 * #1099 * #1100 * #1102 * #1103 * #1104 * #1105 * #1106 * #1109 * #1110 * #1111 * #1112 * #1114 * #1116 * #1117 * #1118 * #1119 * #1120 * #1121 * #1122 * #1123 * #1125 * #1126 * #1127 * #1128 * #1129 * #1130 * #1131 * #1132 * #1133 * #1134 * #1135 * #1136 * #1138 * #1139 * #1140 * #1141 * #1142 * #1143 * #1144 * #1145 * #1146 * #1147 * #1148 * #1149 * #1151 * #1152 * #1153 * #1154 * #1155 * #1156 * #1157 * #1158 * #1160 * #1161 * #1162 * #1163 * #1164 * #1165 * #1166 * #1167 * #1168 * #1169 * #1170 * #1171 * #1172 * #1173 * #1174 * #1175 * #1177 * #1178 * #1180 * #1181 * #1182 * #1183 * #1184 * #1185 * #1187 * #1188 * #1189 * #1190 * #1191 * #1192 * #1193 * #1194 * #1195 * #1196 * #1198 * #1199 * #1200 * #1201 * #1203 * #1204 * #1205 * #1206 * #1207 * #1208 * #1209 * #1210 * #1211 * #1212 * #1213 * #1214 * #1215 * #1216 * #1217 * #1219 * #1220 * #1221 * #1222 * #1223 * #1224 * #1225 * #1226 * #1227 * #1229
Problem
Users section in architecture_2024 is disabled
Solution
Readd it using http API.
Testing
Only issue found during testing is that some put/delete request does not respond body in this PR and js part complain as it always expect json.
Screenshots