Előzmények
gusty | hozzászólásai | válasz erre | 2017.12.20 15:12:08 (1271) |
Sikerült végre megtalálni. Köszi a jelzést, lemaradt egy (). :)
Frissítettem az adatbázist, így ne felejtsetek el új api kulcsot generálni.
[ előzmény: (1268) petrot81, 2017.12.20 08:51:25] |
|
petrot81 | hozzászólásai | válasz erre | 2017.12.20 08:51:25 (1268) |
Nálam továbbra is rossz. Kitöröltem minden logot (több egyéb log is volt tesztként), de továbbra is hozza.
Amit küldök:
userid: 97337
apikey: S43vf1nKTtAYNn1k (ez még él, nem kértem újat)
cacheid: 1732
cachepass: a helyes jelszó
logtype: 1
notes: blabla
logdate: 2017-08-21 12:34:56
Egyéb loggal működik, 1-es type-al jön az említett hiba.
A 1732-981 összetett index miből jön? Mi a 981? Ez lehet a probléma kulcsa. Valami benne maradhat a DB-ben log törlés után is.[ előzmény: (1267) gusty, 2017.12.19 22:42:30] |
|
petrot81 | hozzászólásai | válasz erre | 2017.12.19 09:33:26 (1266) |
Most néztem, hogy a korábbi működő postmanes tesztben is elhasal a log mentés, az említett hibával:
"SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1732-981' for key 'PRIMARY'"[ előzmény: (1262) petrot81, 2017.12.18 09:24:52] |
|
petrot81 | hozzászólásai | válasz erre | 2017.12.18 09:24:52 (1262) |
Az nem baj, csak lényeg, hogy pontosan a rekord struktúra legyen :)
Viszont találtam egy újabb apró bugot: az említett PUT-os visszítérési értékben a logtype szöveges, nem id.
UPD:
Másik bug:
"SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '2005-11672' for key 'PRIMARY'"
2005-ös láda (pusztaszeri emlékmű), a jelszó jó mert már megtaláltam pár hete. Viszont ez az összetett index gyanús, a 11672 a userid lenne? mert én nem ezt küldtem. [ előzmény: (1261) gusty, 2017.12.18 08:46:48] |
|
petrot81 | hozzászólásai | válasz erre | 2017.12.18 08:17:21 (1260) |
Igen, működik, köszönöm!!
Még 1 apróság :)
1) lehetne, hogy a log POST is visszaadja a teljes rekordot, mint a PUT? Most post után külön kérem le az új log adatait, ezt meg lehetne spórolni, ha rögtön visszakapjuk (most csak az id-t küldi vissza az api)
[ előzmény: (1259) gusty, 2017.12.17 21:56:00] |
|
gusty | hozzászólásai | válasz erre | 2017.12.17 21:56:00 (1259) |
Bocs, volt benne még egy ellenőrzés, ott nem volt engedélyezve az OPTIONS.
Nekem most jónak tűnik.
[ előzmény: (1258) petrot81, 2017.12.17 21:19:00] |
|
petrot81 | hozzászólásai | válasz erre | 2017.12.17 17:20:08 (1255) |
Továbbra sem jó :(
Úgy olvastam, hogy az option method-ra is kell egy üres végpont, ami 20x-el tér vissza, hogy lefusson a kérés. Most az jön vissza hibaként is, hogy "Érvénytelen művelet"[ előzmény: (1254) gusty, 2017.12.17 12:18:58] |
|
gusty | hozzászólásai | válasz erre | 2017.12.17 12:18:58 (1254) |
Bocs,
Access-Control-Allow-Methods: GET,PUT,POST,DELETE,OPTIONS
ezt a sort valamiért kikommenteztem, már nem emlékszem miért, s elfelejtettem visszarakni.
Most próbáld.
[ előzmény: (1253) petrot81, 2017.12.17 01:01:30] |
|
petrot81 | hozzászólásai | válasz erre | 2017.12.17 01:01:30 (1253) |
Ismét API..
A logoknál a PUT és DELETE előtt a böngésző küld egy OPTIONS kérést is, ez viszont rendszeresen lehal. Swaggerben és postmanben jó, de fejlesztésnél a böngészőben a cross-domain miatt megy az említett metódus és kilövi a tényleges kérést.
Request URL:https://api.geolada.hu/userlog
Request Method:OPTIONS
Status Code:405 Method Not Allowed
Remote Address:217.13.101.139:443
Referrer Policy:no-referrer-when-downgrade
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests
Elviekben szerver beállítás orvosolná:
Access-Control-Allow-Methods: GET,PUT,POST,DELETE,OPTIONS
Access-Control-Allow-Origin: * |
|
|
|