rwth-i5-idsg / bikeman Goto Github PK

Verlinkung der Stationen in der Transaktionsübersicht.

In StatusController the implementation to handle charging status notification is missing.

• check if pedelec exists (when not, show error)
• update charging information for pedelec

improve the current situation [1], for example, by using ConcurrentWebSocketSessionDecorator [2]

[1] https://github.com/RWTH-i5-IDSG/BikeMan/blob/sessionbased-auth/src/main/java/de/rwth/idsg/bikeman/ixsi/impl/ProducerImpl.java#L79-L91
[2] https://github.com/spring-projects/spring-framework/blob/master/spring-websocket/src/main/java/org/springframework/web/socket/handler/ConcurrentWebSocketSessionDecorator.java

For example SystemID element should be of type String, rather than SystemID -> SystemIDType -> String. Avoiding this boilerplate, would make it easier for the developer.

Save websocket connections and establish push message architecture

w.r.t. commit b09ce4d :

this style of pagination might be problematic, if the hibernate generated queries translate to "select ... offset .. limit .."

such queries should never be used. for more info, links; see: steve-community/steve#1

We should secure the ps interface by restricting the allowed ip range. This means only changing the one line [1] to ".hasIpAddress()" with the correct expression.

[1] https://github.com/RWTH-i5-IDSG/BikeMan/blob/sessionbased-auth/src/main/java/de/rwth/idsg/bikeman/config/SecurityConfiguration.java#L116

In StatusController the implementation to handle station status notification is missing.

• check if station exists (when not, show error)
• validate?
• update station and slots

Endpoint Attribute is not part of the frontend. After updating a station, the endpoint (and maybe other values) get cleared.

in StatusController the implementation to handle pedelec status notification is missing.

• check if pedelec exists (when not, show error)
• check position of pedelec (when current position not same as new, show error)
• update pedelec

Last update steht für Last charging update. Dieses stimmt nicht mit dem Last station update überein.

We need some filters for the transaction overview (order by name, date, ...) and filter by a specific time range, pedelec, station, ...

backend provides the logs via the api now [1]. the frontend ui must be adapted to be able to request them. the response is plain text.

[1] https://github.com/RWTH-i5-IDSG/BikeMan/blob/sessionbased-auth/src/main/java/de/rwth/idsg/bikeman/web/rest/LogsResource.java#L73

we introduced reservation states [1] to better handle the lifecycle of a reservation. they should also be taken into account in db calls of the mobile app.

[1] https://github.com/RWTH-i5-IDSG/BikeMan/blob/sessionbased-auth/src/main/java/de/rwth/idsg/bikeman/domain/ReservationState.java

With a known session id (from myself or sniffed), it is possible to change the password without any confirmation. In combination with Issue #26 it is possible to steal a complete user account without (direct) knowledge of the user (For example if the user left the session open on a public computer).

The following curl command outlines this:

curl --request POST \
  --url http://127.0.0.1:8080/api/account/change_password \
  --header 'content-type: application/json' \
  --cookie JSESSIONID={{ YOUR SESSION ID }} \
  --data '{{ NEW_PASSWORD }}'

validate that the user trying to change/cancel/unlock the booking is the same as the one who created the booking

Since we introduced CardAccounts and they also have the inTransaction fields, inTransaction in Customer should be removed. I think we left them untouched because the frontend was already implemented and was depending on them.

Transactions werden nicht nach Datum sortiert.
Lösungsvorschlag: zuletzt gestartete Transaktionen oben anzeigen

With a known session id (from myself or sniffed), it is possible to change the E-Mail address without any confirmation. The following curl command outlines this:

curl --request POST \
  --url http://127.0.0.1:8080/api/account \
  --header 'content-type: application/json' \
  --cookie JSESSIONID={{ YOUR SESSION ID }} \
  --data '{"login": "[email protected]", "roles": []}'

In the Station-Overview and Station-Details (position is missing) the slots have to be ordered by the slot position (ASC)

usecase to reproduce: when one address field of a customer is updated, "updated" timestamp remains the same.