Ok, so I should just redirect back to the new_proof_url endpoint, fair enough
yeah. redirecting is perfect. it doesn’t have to redirect to new it could also go to the user’s profile page or settings page or something like that as long as the flash notice tells the user something actionable. whatever makes the most sense. i’m not really sure. no opinions.
the logged-in user is the discourse user that is making the proof
absolutely. yes. it looked like here we’re only checking if it’s the correct user on create and i’d argue we should also do it on new. there’s no sense in trying to save a proof that we know will fail.
The code I pushed is not the latest. I rewrote the create method, removing the check for the username param as it should not be necessary anymore (as the proof_valid? check will fail).
The new method is just a placeholder for Discourse routing logic, it will never be called and it needs to allow non-logged-in requests to allow the user to log in if they logged off previously
EDIT: this is the new code I just pushed (still not very polished, I pushed it just to let you see it).
I am having issues updating the proof custom field. The first time I put a JSON object in it, it works, but any attempt to change the value of the custom field fails. This is the code:
def create
kb_username = params.fetch('kb_username')
sig_hash = params.fetch('sig_hash')
proof = Proof.new(current_user.username, kb_username, sig_hash)
unless proof.valid?
raise Discourse::InvalidParameters, I18n.t('keybase_proofs.invalid_proof')
end
proofs = current_user.custom_fields['keybase_proofs'] || {}
# Override the signature because the old one might have been
# revoked and not yet updated on our side.
proofs[kb_username] = proof.signature
current_user.custom_fields['keybase_proofs'] = proofs
current_user.save
render json: success_json
end
the first time this code is called, it adds the proofs to the custom field named "keybase_proofs". If I call it again, it doesn’t update the custom field.
Some more information: if I change the type of the custom field to a string, it works correctly.
Is not returning a hash, so on the first time it works because you coalesce it to an empty Hash. But it fails on subsequent tries because it’s returning something else.
Unfortunately not. Since I am learning how everything works together, my code is almost always in a very sad shape, not really worth pushing. But the code that is in GitHub shows exactly the same issue (but I didn’t push the tests).
In the latest version of the code, which I have locally, I got rid of the JSON type and I am just using serialized JSON strings instead, and it is now working fine.
This is not the case. When I say that “it fails”, I mean “it fails to update” the field. So the first time the code runs, it saves the custom field correctly (I can also retrieve it, I use the data in the profile page and in the check proof endpoint). The second time I run the code (ie, if I add another Keybase identity to the same Discourse user), the custom field is not updated, it keeps only the first signature I added.
In case you’re curious and you want to debug the issue, I’ll create a branch with the original code and tests (that were failing) so you can investigate
Unfortunately I don’t know how to do it for this codebase using VS Code do you have any advice on an alternative editor? RubyMine?
You can add a byebug to any line in the controller, and when that line is hit the console where you started the webserver (the one you run bin/unicorn -x) will stop and allow you to inspect the variables.
The debugger confirms what I saw with previous testing: the JSON is stored the first time, and any attempt to change it later gets silently ignored. Anyway, for now I have fixed it by manually parsing/encoding the JSON string in the custom field.
It should mostly work. There are a few things to fix before it is “shippable”:
The “new proof” UI needs some CSS love. It should also show an error if the logged in user is not the one for which the proof is requested.
The config endpoint /keybase-proofs/config needs a couple of SVG logos, but I don’t know where to get them from. Ideas? @kb_xgess, do they need to be SVG? Do you need both the black&white and the colored one?
redirect-after-login doesn’t work currently. @techAPJ is investigating, might be a bug in Discourse core or (more likely?) a bug somewhere in the plugin.
Some notes on code quality:
I didn’t write frontend tests. I think I’ve got the gist of how to write tests for components, but I didn’t want to spend more time figuring out how to mock requests and so on.
proof_controller.rb has a very ugly pic_url method, needed because I couldn’t make the call to the keybase API from the client because of CORS. I guess it can be moved to somewhere else or someone can figure out how to fetch the information from the client side.
I didn’t run any linter/formatter on the code. Should I?
ألقِ نظرة على بعض أكوادك الآن. تقدم رائع! سؤال سريع حول meta.discourse.org، هل يعمل على قاعدة كود مختلفة؟ هل يمكننا نشر كودك عليه؟ أسأل لأن جزءًا من بروتوكول التبادل المتبادل هو أن Keybase يتصل بـ Discourse للتحقق من الدليل المضيف. إذا لم يكن موجودًا، سيفشل كل شيء. لذا، قد يكون من الأسهل لك التطوير على خادم عام أقل إنتاجية. إذا كان ذلك منطقيًا. ربما بيئة تجريبية أو بيئة تطوير مستضافة. أو حتى إذا كان لديك حساب مع ngrok، يمكننا إنشاء عنوان URL ثابت يقوم دائمًا بالتوجيه إلى localhost الخاص بك ويكون نشطًا فقط عندما تريده (من جانبك بالكامل). إذا كان لديك المرونة اللازمة على meta.discourse.org، يمكنني تفعيله لهذا الموقع باستخدام الإعدادات الموجودة في كودك وبعض الإعدادات الافتراضية الأخرى.
سؤال آخر حول ملفات SVG. تُعد ملفات SVG مثالية لأننا في الواقع نحتاج إلى مجموعة من ملفات PNG بأحجام مختلفة لتطبيق الهاتف المحمول، وتطبيق سطح المكتب، والموقع الإلكتروني، ومن المرجح أن يكون الأمر أسهل للجميع إذا أمكننا تصييرها جميعًا من نفس المدخلات الأولية.
هذا محبط. هل هذا ضروري حقًا، @kb_xgess؟ كنت أتمنى أنه يمكن للمرء ببساطة، على سبيل المثال، تزويد Keybase برابط لملف شخصي على أي خادم Discourse يشغل الإضافة (أو أي خادم Discourse إذا تم دمجها في النواة)، وبالتالي يمكن إثبات ذلك على أي خادم Discourse.
نعم، الخطة هي إنشاء جميع الأدوات اللازمة، وأنا متأكد من أن @kb_xgess ستمكّنها للمجتمعات التي يكون فيها ذلك منطقيًا. هذا لا يعني أن كل بلدة أشباح أو مثيل يتطلب تسجيل الدخول سيحصل عليها.
do you have any advice on an alternative editor? RubyMine?
