Age | Commit message (Collapse) | Author |
|
strings used to check everything's fine manually.
|
|
(not included here, still to decide if push it publicly).
Next steps: make code beautiful, Android GUI SRP and real
communication server, and add even more tests (in my spare time, just to
check with more users).
|
|
tests I've written for it.
Next step: verify()
|
|
individually are. But in reality it's not.
Tried to fix final hash putting a trim in every byte array, but it did
not work.
Next step: check the final hash, looking for padding issues.
|
|
Next step: fix response() calculations.
|
|
Next step: understand why SHA-256 digest from NG_1024 is not equals to
the one leap_web is calculating.
|
|
|
|
calculation, since right now (using tests) response() method is not
doing OK.
Added new SRPSession modifying response() method from JBoss SRP
implementation.
Added hosts-for-android-emulator. Use with the following commands to be
able to test on api.lvh.me:
adb shell mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
adb push ~/workspace/leap_android/hosts-for-android-emulator
/system/etc/hosts
|
|
not SRP-6a. That means, for example, that M1 is calculated differently
from what we need.
|
|
the salt, and because of our messageflow I cannot obtain it before
starting Authentication. That's why on line 132 from ProviderAPI I tried
to get a new SRPClientSession using the newly obtained salt, but of
course it fails since A cannot be restored from previous initialization.
Next step: try with srpforjava.
Next next step: if srpforjava does not work for us, use lower level
methods to implement our own http srp flow.
|
|
errors because of classes not yet found.
|
|
Going to hit some bugs before continuing with this work.
|
|
will have to audit it.
|
|
Cleaned some code, pending the M2 one (testing with M1).
|
|
M1 is not OK, because errors (with null description, awkward) are
received from posting M1 to the server instead of M2.
Next step: purge user database from leap_webapp and start testing again.
|
|
Refactored downloadJsonFiles in ProviderAPI, new method from block in
the intent identification.
|
|
|
|
Next step: get cookies understood, how do I get server's sent
parameters?
|
|
Next steps:
Implement async communication with the server to receive salt, send A
and receive B.
|
|
|
|
and USR documents -> Next week I'll work on them
|
|
diagram.
Use case diagram is complete about future releases (all services, email,
chat...).
Components diagram should be discussed, I feel far from final solution.
|
|
The problem was that ProviderItem.custom was not being set by the
constructor, and when using this variable from ConfigurationWizard to
get providers.json from http or from assets file.
|
|
ProviderListFragment, and then the user can choose it.
|
|
the website, just as bitmask.net/provider.json), and writes it to a file
in ~/leap_android.
Next steps: parse that file and download eip-service and cert.
|
|
The problem in the previous commit was that I had to modify the fragment
layout, instead of that of the Activity. I learnt how to obtain and
modify it from here:
https://developer.android.com/reference/android/app/ListFragment.html
|
|
Trying to test cancel button from created new dialog.
|
|
|
|
|
|
Moves towards our wizard flow; Addresses #1497 #1500
|
|
|
|
|
|
|
|
protected
|
|
Conflicts:
src/se/leap/leapclient/Dashboard.java
|
|
in eip.
Downloads certificate and eip from web, and loads provider from assets.
KeyStore not created with latest version of BouncyCastle. Looking
forward to file a bug and look for a solution.
|
|
had ProviderList stuff)
|
|
have no config (createed NullPointerExceptions)
|
|
|
|
and bitmask.net.
Both prefs are downloaded and parsed to SharedPreferences.
|
|
|
|
the saveSharedPrefs method and an unimplemented rescueFromJSONException.
Next step: managing HttpsURLConnection for the
CertPathValidatorException.
|
|
eip-service.json file.
provider.json downloads and parses itself OK to SharedPreferences.
It also does not link OK to the Dashboard, I do not know how to do it
properly and I'm so tired (eyes hurting).
Beginning with security things :) Happy to have gotten around
DownloadManager problem with a simple HTTP connection.
|
|
downloaded.
Seen http://code.google.com/p/android/issues/detail?id=18462 and decided
to look for another solution.
First solution thought (and going to be the next test): HTTP Get request
:)
|
|
Added parts to expand listing for quick info and settings access
|
|
|
|
variety,
And there shady json files...Creates Issue #1593
|
|
Needs attention, as the AboutFragment does not fill the layout
You can still see providerLine
Creates Issue #1592
|
|
|
|
Matching layout and menu XML
And don't forget strings
|